Thanks Daniel,
Excellent information.
I had a thought on the patch, what if the iio part were something that ‘could
be implemented’ by end developers (as the hardware dictated), but a way to
rotate
would exist. Maybe an ipc socket could be a generic means to implement a
rotation. That way, a rotation patch could be merged, and as people needed it,
they could use whatever means to determine when to issue a rotation. We plan
to ultimately depend on a tilt switch to programmatically rotate, but my
starting point
will be a socket to test with; as we don’t have our hardware built yet. Just a
thought.
Oh and Emmanuel, I was serious about getting you guys lunch. As I said, if it
worked, I’d owe you lunch.
-dwd
David
Deyo
[cid:image003.png@01D78A9B.30406710]
Firmware Engineer
TPI- Tire Profiles
O: 214-396-3063
E: dd...@tireprofiles.com<mailto:dd...@tireprofiles.com> | W:
www.tireprofiles.com<http://www.tireprofiles.com/>
A: 3010 Story Rd W, Irving, TX 75038
From: Daniel Stone<mailto:dan...@fooishbar.org>
Sent: Friday, August 6, 2021 3:14 AM
To: David Deyo<mailto:dd...@tireprofiles.com>
Cc: Emmanuel Gil Peyrot<mailto:linkma...@linkmauve.fr>;
wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org>
Subject: Re: FW: xrandr and xwayland
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
Hi David,
On Thu, 5 Aug 2021 at 22:17, David Deyo <dd...@tireprofiles.com> wrote:
> > Sounds like you're missing wl_display_flush() in your client code, so the
> > requests don't make it to the socket buffer until they're forced to because
> > it's filled up.
>
> That did it. You guys are awesome. I don’t suppose there’s a Weston doc
> somewhere that would have told me that, had I looked.
It's a little bit buried, but this is the best explanation of how to
integrate Wayland into an event loop, as you would with a toolkit:
https://wayland.freedesktop.org/docs/html/apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0
If you scroll up to the main wl_display section, it explains how event
queues are used as well.
Broadly speaking, the advice is to:
- when active, process your events and send any requests
- immediately before you go into a passive state (waiting for events,
sleeping, etc), flush the display so your requests get delivered
- run the prepare_read_queue() / dispatch_queue_pending() loop
immediately before sleeping, in order to make sure you get all events
queued for you, then flush again in case you've queued any requests
from your event handlers
- poll on the Wayland display FD as well as any other activity sources
(other event queues, timers, etc)
- when you wake up, dispatch your Wayland event queue as well as other
relevant event sources
> > Also, my taskbar is the wrong length and my background is black. Other
> > than that, pretty cool.
>
> Yep, desktop-shell isn't designed to handle runtime rotation. It could be
> made to pretty easily by working on the client code. For your case though I'd
> assume something like kiosk-shell would be a much better bet.
kiosk-shell is something we have in newer versions of Weston which
sounds like it would work well for your usecases - it's designed to
just run a single application fullscreen. You might want to check out
what we have in git, which will be released as 10.0 in a few weeks'
time.
The rotation patches never got merged because we had some issues with
the IIO integration in particular, but having runtime rotation tests
sure would be nice, and kiosk-shell should at least be a lot easier to
fix than desktop-shell, if it does even need any fixes.
Cheers,
Daniel
