Re: FW: xrandr and xwayland

[Guillermo Rodriguez Garcia]

Hi Daniel,

El vie, 6 ago 2021 a las 11:57, Daniel Stone ()
escribió:

> Hi Guillermo,
>
> On Fri, 6 Aug 2021 at 10:44, Guillermo Rodriguez Garcia
>  wrote:
> > El vie, 6 ago 2021 a las 10:14, Daniel Stone ()
> escribió:
> >> 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.
> >
> > I have a use case for this which is conceptually one single application,
> fullscreen, no desktop stuff (navigation bar, window management etc) but
> needs to support additional processes with separate top-level windows. This
> would be used e.g. to overlay a video stream (using gstreamer) on top of
> the "main" application. Will this be supported by kiosk-shell ?
>
> For clients to be able to position themselves relative to other
> clients, wl_subcompositor gives you the subsurface mechanism for
> embedding. This was designed for this exact usecase: an application
> embedding media content in its own top-level window. Using this is
> very strongly recommended.
>

But does this require that both "clients" run as the same process? I assume
that's the case since I need to pass a handle of the parent wl_surface in
order to create a subsurface.

An important part of the problem is that we need to run the main
application and the gstreamer client as separate processes.

Thanks,

Guillermo


> If you are unable to do this for whatever reason, then you will need
> to customise the window manager - in this case, kiosk-shell. We are
> planning to extend this with Lua scripting to make this easier, but
> have no firmly-defined ETA for this right now.
>
> Cheers,
> Daniel
>


-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com

RE: FW: xrandr and xwayland

[David Deyo]

Hey Daniel,

It seems if my rotation is 0 or 180, touch works correctly.  Maybe it’s related 
to whether my button array fits on the screen entirely.

If it’s 90 or 270 (or if the image is partially off-screen), the touch 
coordinates are off.

Does anyone have any idea where I should look to align the touch with the 
button array, if the button widget is partially off-screen?

-dwd




 David 
Deyo
[cid:image003.png@01D78AE0.D0AFD290]

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  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

RE: FW: xrandr and xwayland

[David Deyo]

Thanks Daniel,

My local test is just a timer that rotates every 5 seconds.  I have a python 
keyboard running that rotates, but I have remnants of the original keyboard.
Almost like I have a stale buffer.  The extra keyboard images don’t respond 
either.

Is there some clear I need to be calling before I rotate?

-dwd

 David 
Deyo
[cid:image003.png@01D78AB0.80A0FBB0]

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  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

RE: FW: xrandr and xwayland

[David Deyo]

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  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

Re: FW: xrandr and xwayland

[Daniel Stone]

Hi Guillermo,

On Fri, 6 Aug 2021 at 10:44, Guillermo Rodriguez Garcia
 wrote:
> El vie, 6 ago 2021 a las 10:14, Daniel Stone () 
> escribió:
>> 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.
>
> I have a use case for this which is conceptually one single application, 
> fullscreen, no desktop stuff (navigation bar, window management etc) but 
> needs to support additional processes with separate top-level windows. This 
> would be used e.g. to overlay a video stream (using gstreamer) on top of the 
> "main" application. Will this be supported by kiosk-shell ?

For clients to be able to position themselves relative to other
clients, wl_subcompositor gives you the subsurface mechanism for
embedding. This was designed for this exact usecase: an application
embedding media content in its own top-level window. Using this is
very strongly recommended.

If you are unable to do this for whatever reason, then you will need
to customise the window manager - in this case, kiosk-shell. We are
planning to extend this with Lua scripting to make this easier, but
have no firmly-defined ETA for this right now.

Cheers,
Daniel

Re: FW: xrandr and xwayland

[Guillermo Rodriguez Garcia]

Hi Daniel,

El vie, 6 ago 2021 a las 10:14, Daniel Stone ()
escribió:

> 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.
>

I have a use case for this which is conceptually one single application,
fullscreen, no desktop stuff (navigation bar, window management etc) but
needs to support additional processes with separate top-level windows. This
would be used e.g. to overlay a video stream (using gstreamer) on top of
the "main" application. Will this be supported by kiosk-shell ?

BR,

guille.rodrig...@gmail.com

Re: FW: xrandr and xwayland

[Daniel Stone]

Hi David,

On Thu, 5 Aug 2021 at 22:17, David Deyo  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

RE: FW: xrandr and xwayland

[David Deyo]

From: Daniel Stone<mailto:dan...@fooishbar.org>
Sent: Thursday, August 5, 2021 3:57 PM
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.

On Thu, 5 Aug 2021 at 21:15, David Deyo 
mailto:dd...@tireprofiles.com>> wrote:
I was able to re-create the files of your patch and added them into my build 
tree.

Not having an accelerometer, I’ve had to make a few changes.
When you said, ‘It had issues’, I am also seeing some issues.

I can rotate my screen, but something about the callback (weston_rotate_rotate) 
is acting strange.
I have added a loop in autorotate that calls weston_rotate_rotate every 10 
secs.   I am logging out to Weston_log.
It seems I only get those logs once every 15-30 minutes and when I do, it’s 
hundreds of logs.  What’s up with that?


  *   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.

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.


  *   Cheers,



  *   Daniel

Thanks  everyone (especially Emmanuel and Daniel),

-dwd

RE: FW: xrandr and xwayland

[David Deyo]

On Thu, 5 Aug 2021 at 21:15, David Deyo 
mailto:dd...@tireprofiles.com>> wrote:
I was able to re-create the files of your patch and added them into my build 
tree.

Not having an accelerometer, I’ve had to make a few changes.
When you said, ‘It had issues’, I am also seeing some issues.

I can rotate my screen, but something about the callback (weston_rotate_rotate) 
is acting strange.
I have added a loop in autorotate that calls weston_rotate_rotate every 10 
secs.   I am logging out to Weston_log.
It seems I only get those logs once every 15-30 minutes and when I do, it’s 
hundreds of logs.  What’s up with that?


  *   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.
I’ll have a look, thanks.

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.
Is there such a thing as kiosk-shell?  Or is that what you’re calling this 
effort?


  *   Cheers,

  *   Daniel

Thanks,

-dwd

Re: FW: xrandr and xwayland

[Daniel Stone]

On Thu, 5 Aug 2021 at 21:15, David Deyo  wrote:

> I was able to re-create the files of your patch and added them into my
> build tree.
>
>
>
> Not having an accelerometer, I’ve had to make a few changes.
>
> When you said, ‘It had issues’, I am also seeing some issues.
>
>
>
> I can rotate my screen, but something about the callback
> (weston_rotate_rotate) is acting strange.
>
> I have added a loop in autorotate that calls weston_rotate_rotate every 10
> secs.   I am logging out to Weston_log.
>
> It seems I only get those logs once every 15-30 minutes and when I do,
> it’s hundreds of logs.  What’s up with that?
>

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.


> 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.

Cheers,
Daniel

RE: FW: xrandr and xwayland

[David Deyo]

Hello,

I was able to re-create the files of your patch and added them into my build 
tree.

Not having an accelerometer, I’ve had to make a few changes.
When you said, ‘It had issues’, I am also seeing some issues.

I can rotate my screen, but something about the callback (weston_rotate_rotate) 
is acting strange.
I have added a loop in autorotate that calls weston_rotate_rotate every 10 
secs.   I am logging out to Weston_log.
It seems I only get those logs once every 15-30 minutes and when I do, it’s 
hundreds of logs.  What’s up with that?

Also, my taskbar is the wrong length and my background is black.  Other than 
that, pretty cool.

You can’t remember what issues there were before?

Thanks again,


-dwd
 David 
Deyo
[cid:image003.png@01D78A0C.BBC29090]

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: Emmanuel Gil Peyrot<mailto:linkma...@linkmauve.fr>
Sent: Tuesday, August 3, 2021 11:00 AM
To: David Deyo<mailto:dd...@tireprofiles.com>
Cc: 
wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org>
Subject: Re: FW: xrandr and xwayland

Hi,

On Tue, Aug 03, 2021 at 01:04:11PM +, David Deyo wrote:
[…]
> I believe our compositor (Weston) can do it, transform=90, but to use this 
> method, it has to be restarted; causing our gui app to crash and lose all 
> entered data.
> The client probably needs to drive the orientation.   Considering our gui 
> will likely be in python3/tkinter, I will need some way create a page and 
> rotate the display.

I once implemented such a plugin[1] for Weston, it never got merged
because it had issues I don’t completely remember, but could be a good
starting point.

It relies on the iio subsystem to provide accelerometer data, and then
automatically rotates once it detects the display is sideways.

Hope it’ll help. :)

[1] https://lists.freedesktop.org/archives/wayland-devel/2016-August/030396.html

--
Emmanuel Gil Peyrot

Re: FW: xrandr and xwayland

[Emmanuel Gil Peyrot]

Hi,

On Tue, Aug 03, 2021 at 01:04:11PM +, David Deyo wrote:
[…]
> I believe our compositor (Weston) can do it, transform=90, but to use this 
> method, it has to be restarted; causing our gui app to crash and lose all 
> entered data.
> The client probably needs to drive the orientation.   Considering our gui 
> will likely be in python3/tkinter, I will need some way create a page and 
> rotate the display.

I once implemented such a plugin[1] for Weston, it never got merged
because it had issues I don’t completely remember, but could be a good
starting point.

It relies on the iio subsystem to provide accelerometer data, and then
automatically rotates once it detects the display is sideways.

Hope it’ll help. :)

[1] https://lists.freedesktop.org/archives/wayland-devel/2016-August/030396.html

-- 
Emmanuel Gil Peyrot


signature.asc
Description: PGP signature

RE: FW: xrandr and xwayland

[David Deyo]

From: Carsten Haitzler<mailto:ras...@rasterman.com>
Sent: Tuesday, August 3, 2021 10:47 AM
To: David Deyo<mailto:dd...@tireprofiles.com>
Cc: 
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.


On Tue, 3 Aug 2021 15:00:44 + David Deyo  said:

>
>
> From: Carsten Haitzler<mailto:ras...@rasterman.com>
> Sent: Tuesday, August 3, 2021 9:38 AM
> To: David Deyo<mailto:dd...@tireprofiles.com>
> Cc:
> 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.
>
>
> On Tue, 3 Aug 2021 13:40:25 + David Deyo  said:
>
> > From: Carsten Haitzler<mailto:ras...@rasterman.com>
> > Sent: Tuesday, August 3, 2021 8:13 AM
> > To: David Deyo<mailto:dd...@tireprofiles.com>
> > Cc:
> > 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.
> >
> >
> > On Tue, 3 Aug 2021 13:04:11 + David Deyo  said:
> >
> > >
> > >
> > > From: David Deyo<mailto:dd...@tireprofiles.com>
> > > Sent: Monday, August 2, 2021 3:53 PM
> > > To: Pekka Paalanen<mailto:ppaala...@gmail.com>
> > > Subject: RE: xrandr and xwayland
> > >
> > > On Fri, 30 Jul 2021 23:30:38 +0100
> > > Carsten Haitzler  wrote:
> > >
> > > > On Fri, 30 Jul 2021 16:28:02 + David Deyo 
> > > > said:
> > > >
> > > > No - this is up to the compositor itself to do in its own internal ways.
> > > > Far too many abuses have happened over the years with xrandr available
> > > > to any client anywhere. While in theory a wayland compositor could
> > > > create an extension that works like xrandr, it'd be problematic to make
> > > > it general-access like xrandr.
> > >
> > > >>>Indeed.
> > >
> > > > >
> > > > > Hello  everyone,
> > > > >
> > > > > I need to rotate  my screen 90 degrees and back to normal in xwayland
> > > > > on an iMX8 running gatesgarth distro.
> > >
> > > >>>Maybe you could explain your top-level use case for this, and the
> > > >>>general system architecture (which relevant programs are running and
> > > >>>what their responsibilities are)?
> > >
> > > Distro:
> > > I am working on a product that our company is creating.  It uses an imx8
> > > som from Boundary.  The system is not a normal desktop. The DISTRO is
> > > created by yocto using the gatesgarth branch.  Just recently we were
> > > notified that Xwayland was working, so I don’t expect we will be removing
> > > it just yet.
> > >
> > >
> > > Use case:
> > > We will have a kiosk-looking desktop.  Some of our pages will have the
> > > option for the end user to enter text from an on-screen keyboard. Since
> > > our display will be so small (68.04mm (2.68") x 120.96mm (4.76")), we
> > > will have to turn our unit sideways to make the keyboard fit.  We have
> > > already done this on a smaller screen (1.0). On our 1.0 product, we used
> > > Segger as our graphics library.  Compared to Android, and the like, it
> > > seems like rotating the screen would be a standard capability.
> > >
> > > I believe our compositor (Weston) can do it, transform=90, but to use this
> > > method, it has to be restarted; causing our gui app to crash and lose all
> > > entered data. The client probably needs to drive the orientation.
> > > Considering our gui will likely be in python3/tkinter, I will need some
> > > way create a page and rotate the display.
> > >
> > > I am somewhat limited by the packages available to me in my distro.
> >
> > > > > >The right way here is to modify Weston to do on-the-fly rotation
> > > > > >without a restart. You also will want a custom protocol from client

Re: FW: xrandr and xwayland

[Carsten Haitzler]

On Tue, 3 Aug 2021 15:00:44 + David Deyo  said:

> 
> 
> From: Carsten Haitzler<mailto:ras...@rasterman.com>
> Sent: Tuesday, August 3, 2021 9:38 AM
> To: David Deyo<mailto:dd...@tireprofiles.com>
> Cc:
> 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.
> 
> 
> On Tue, 3 Aug 2021 13:40:25 + David Deyo  said:
> 
> > From: Carsten Haitzler<mailto:ras...@rasterman.com>
> > Sent: Tuesday, August 3, 2021 8:13 AM
> > To: David Deyo<mailto:dd...@tireprofiles.com>
> > Cc:
> > 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.
> >
> >
> > On Tue, 3 Aug 2021 13:04:11 + David Deyo  said:
> >
> > >
> > >
> > > From: David Deyo<mailto:dd...@tireprofiles.com>
> > > Sent: Monday, August 2, 2021 3:53 PM
> > > To: Pekka Paalanen<mailto:ppaala...@gmail.com>
> > > Subject: RE: xrandr and xwayland
> > >
> > > On Fri, 30 Jul 2021 23:30:38 +0100
> > > Carsten Haitzler  wrote:
> > >
> > > > On Fri, 30 Jul 2021 16:28:02 + David Deyo 
> > > > said:
> > > >
> > > > No - this is up to the compositor itself to do in its own internal ways.
> > > > Far too many abuses have happened over the years with xrandr available
> > > > to any client anywhere. While in theory a wayland compositor could
> > > > create an extension that works like xrandr, it'd be problematic to make
> > > > it general-access like xrandr.
> > >
> > > >>>Indeed.
> > >
> > > > >
> > > > > Hello  everyone,
> > > > >
> > > > > I need to rotate  my screen 90 degrees and back to normal in xwayland
> > > > > on an iMX8 running gatesgarth distro.
> > >
> > > >>>Maybe you could explain your top-level use case for this, and the
> > > >>>general system architecture (which relevant programs are running and
> > > >>>what their responsibilities are)?
> > >
> > > Distro:
> > > I am working on a product that our company is creating.  It uses an imx8
> > > som from Boundary.  The system is not a normal desktop. The DISTRO is
> > > created by yocto using the gatesgarth branch.  Just recently we were
> > > notified that Xwayland was working, so I don’t expect we will be removing
> > > it just yet.
> > >
> > >
> > > Use case:
> > > We will have a kiosk-looking desktop.  Some of our pages will have the
> > > option for the end user to enter text from an on-screen keyboard. Since
> > > our display will be so small (68.04mm (2.68") x 120.96mm (4.76")), we
> > > will have to turn our unit sideways to make the keyboard fit.  We have
> > > already done this on a smaller screen (1.0). On our 1.0 product, we used
> > > Segger as our graphics library.  Compared to Android, and the like, it
> > > seems like rotating the screen would be a standard capability.
> > >
> > > I believe our compositor (Weston) can do it, transform=90, but to use this
> > > method, it has to be restarted; causing our gui app to crash and lose all
> > > entered data. The client probably needs to drive the orientation.
> > > Considering our gui will likely be in python3/tkinter, I will need some
> > > way create a page and rotate the display.
> > >
> > > I am somewhat limited by the packages available to me in my distro.
> >
> > > > > >The right way here is to modify Weston to do on-the-fly rotation
> > > > > >without a restart. You also will want a custom protocol from client
> > > > > >to compositor to indicate when a client surface wants rotation. This
> > > > > >way the compositor can correctly rotate the client content and any
> > > > > >other on-screen content at the time
> > > > > > (e.g. keyboard) when that client surface is the active visible one
> > > > > > (as a kiosk
> > > > > >style only one will b

RE: FW: xrandr and xwayland

[David Deyo]

From: Carsten Haitzler<mailto:ras...@rasterman.com>
Sent: Tuesday, August 3, 2021 9:38 AM
To: David Deyo<mailto:dd...@tireprofiles.com>
Cc: 
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.


On Tue, 3 Aug 2021 13:40:25 + David Deyo  said:

> From: Carsten Haitzler<mailto:ras...@rasterman.com>
> Sent: Tuesday, August 3, 2021 8:13 AM
> To: David Deyo<mailto:dd...@tireprofiles.com>
> Cc:
> 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.
>
>
> On Tue, 3 Aug 2021 13:04:11 + David Deyo  said:
>
> >
> >
> > From: David Deyo<mailto:dd...@tireprofiles.com>
> > Sent: Monday, August 2, 2021 3:53 PM
> > To: Pekka Paalanen<mailto:ppaala...@gmail.com>
> > Subject: RE: xrandr and xwayland
> >
> > On Fri, 30 Jul 2021 23:30:38 +0100
> > Carsten Haitzler  wrote:
> >
> > > On Fri, 30 Jul 2021 16:28:02 + David Deyo 
> > > said:
> > >
> > > No - this is up to the compositor itself to do in its own internal ways.
> > > Far too many abuses have happened over the years with xrandr available to
> > > any client anywhere. While in theory a wayland compositor could create an
> > > extension that works like xrandr, it'd be problematic to make it
> > > general-access like xrandr.
> >
> > >>>Indeed.
> >
> > > >
> > > > Hello  everyone,
> > > >
> > > > I need to rotate  my screen 90 degrees and back to normal in xwayland on
> > > > an iMX8 running gatesgarth distro.
> >
> > >>>Maybe you could explain your top-level use case for this, and the
> > >>>general system architecture (which relevant programs are running and
> > >>>what their responsibilities are)?
> >
> > Distro:
> > I am working on a product that our company is creating.  It uses an imx8 som
> > from Boundary.  The system is not a normal desktop. The DISTRO is created by
> > yocto using the gatesgarth branch.  Just recently we were notified that
> > Xwayland was working, so I don’t expect we will be removing it just yet.
> >
> >
> > Use case:
> > We will have a kiosk-looking desktop.  Some of our pages will have the
> > option for the end user to enter text from an on-screen keyboard. Since our
> > display will be so small (68.04mm (2.68") x 120.96mm (4.76")), we will have
> > to turn our unit sideways to make the keyboard fit.  We have already done
> > this on a smaller screen (1.0). On our 1.0 product, we used Segger as our
> > graphics library.  Compared to Android, and the like, it seems like
> > rotating the screen would be a standard capability.
> >
> > I believe our compositor (Weston) can do it, transform=90, but to use this
> > method, it has to be restarted; causing our gui app to crash and lose all
> > entered data. The client probably needs to drive the orientation.
> > Considering our gui will likely be in python3/tkinter, I will need some way
> > create a page and rotate the display.
> >
> > I am somewhat limited by the packages available to me in my distro.
>
> > > > >The right way here is to modify Weston to do on-the-fly rotation
> > > > >without a restart. You also will want a custom protocol from client to
> > > > >compositor to indicate when a client surface wants rotation. This way
> > > > >the compositor can correctly rotate the client content and any other
> > > > >on-screen content at the time
> > > > > (e.g. keyboard) when that client surface is the active visible one
> > > > > (as a kiosk
> > > > >style only one will be active/visible at a time - except for things
> > > > >like keyboard etc.). When you switch which surface is the active one
> > > > >then the compositor can re-evaluate how to draw on the screen based on
> > > > >what that client has requested rotation-wise.
> Thank you,
> A custom protocol makes sense.
>
>   1.   What’s the best way to communicate with Weston, socket, message,
> function  call?

> > > > > >Wayland protocol. You can create

Re: FW: xrandr and xwayland

[Carsten Haitzler]

On Tue, 3 Aug 2021 13:40:25 + David Deyo  said:

> From: Carsten Haitzler<mailto:ras...@rasterman.com>
> Sent: Tuesday, August 3, 2021 8:13 AM
> To: David Deyo<mailto:dd...@tireprofiles.com>
> Cc:
> 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.
> 
> 
> On Tue, 3 Aug 2021 13:04:11 + David Deyo  said:
> 
> >
> >
> > From: David Deyo<mailto:dd...@tireprofiles.com>
> > Sent: Monday, August 2, 2021 3:53 PM
> > To: Pekka Paalanen<mailto:ppaala...@gmail.com>
> > Subject: RE: xrandr and xwayland
> >
> > On Fri, 30 Jul 2021 23:30:38 +0100
> > Carsten Haitzler  wrote:
> >
> > > On Fri, 30 Jul 2021 16:28:02 + David Deyo 
> > > said:
> > >
> > > No - this is up to the compositor itself to do in its own internal ways.
> > > Far too many abuses have happened over the years with xrandr available to
> > > any client anywhere. While in theory a wayland compositor could create an
> > > extension that works like xrandr, it'd be problematic to make it
> > > general-access like xrandr.
> >
> > >>>Indeed.
> >
> > > >
> > > > Hello  everyone,
> > > >
> > > > I need to rotate  my screen 90 degrees and back to normal in xwayland on
> > > > an iMX8 running gatesgarth distro.
> >
> > >>>Maybe you could explain your top-level use case for this, and the
> > >>>general system architecture (which relevant programs are running and
> > >>>what their responsibilities are)?
> >
> > Distro:
> > I am working on a product that our company is creating.  It uses an imx8 som
> > from Boundary.  The system is not a normal desktop. The DISTRO is created by
> > yocto using the gatesgarth branch.  Just recently we were notified that
> > Xwayland was working, so I don’t expect we will be removing it just yet.
> >
> >
> > Use case:
> > We will have a kiosk-looking desktop.  Some of our pages will have the
> > option for the end user to enter text from an on-screen keyboard. Since our
> > display will be so small (68.04mm (2.68") x 120.96mm (4.76")), we will have
> > to turn our unit sideways to make the keyboard fit.  We have already done
> > this on a smaller screen (1.0). On our 1.0 product, we used Segger as our
> > graphics library.  Compared to Android, and the like, it seems like
> > rotating the screen would be a standard capability.
> >
> > I believe our compositor (Weston) can do it, transform=90, but to use this
> > method, it has to be restarted; causing our gui app to crash and lose all
> > entered data. The client probably needs to drive the orientation.
> > Considering our gui will likely be in python3/tkinter, I will need some way
> > create a page and rotate the display.
> >
> > I am somewhat limited by the packages available to me in my distro.
> 
> > > > >The right way here is to modify Weston to do on-the-fly rotation
> > > > >without a restart. You also will want a custom protocol from client to
> > > > >compositor to indicate when a client surface wants rotation. This way
> > > > >the compositor can correctly rotate the client content and any other
> > > > >on-screen content at the time
> > > > > (e.g. keyboard) when that client surface is the active visible one
> > > > > (as a kiosk
> > > > >style only one will be active/visible at a time - except for things
> > > > >like keyboard etc.). When you switch which surface is the active one
> > > > >then the compositor can re-evaluate how to draw on the screen based on
> > > > >what that client has requested rotation-wise.
> Thank you,
> A custom protocol makes sense.
> 
>   1.   What’s the best way to communicate with Weston, socket, message,
> function  call?

Wayland protocol. You can create extensions as XML files and use
wayland-scanner to generate C code to handle that protocol.

>   2.  How would Weston actually rotate the display, in particular on the fly?
> In the Weston documentation, it states that a super-kbd key and middle mouse
> button should rotate the display (if supported). I’d like to find where that
> is, as well.

Any number of ways. It could modify the KMS device properties for that output
to rotate. It could render rotated (in GL transform the triangle coordinates
when rendering) or in software render the pixels rotated as you read and write
them from one place to another (various algorithms can be used here). Weston
already can do these so it's just a matter of gluing together the code with
your protocol and some logic.

> -dwd
> --
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

RE: FW: xrandr and xwayland

[David Deyo]

From: Carsten Haitzler<mailto:ras...@rasterman.com>
Sent: Tuesday, August 3, 2021 8:13 AM
To: David Deyo<mailto:dd...@tireprofiles.com>
Cc: 
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.


On Tue, 3 Aug 2021 13:04:11 + David Deyo  said:

>
>
> From: David Deyo<mailto:dd...@tireprofiles.com>
> Sent: Monday, August 2, 2021 3:53 PM
> To: Pekka Paalanen<mailto:ppaala...@gmail.com>
> Subject: RE: xrandr and xwayland
>
> On Fri, 30 Jul 2021 23:30:38 +0100
> Carsten Haitzler  wrote:
>
> > On Fri, 30 Jul 2021 16:28:02 + David Deyo  said:
> >
> > No - this is up to the compositor itself to do in its own internal ways. Far
> > too many abuses have happened over the years with xrandr available to any
> > client anywhere. While in theory a wayland compositor could create an
> > extension that works like xrandr, it'd be problematic to make it
> > general-access like xrandr.
>
> >>>Indeed.
>
> > >
> > > Hello  everyone,
> > >
> > > I need to rotate  my screen 90 degrees and back to normal in xwayland on
> > > an iMX8 running gatesgarth distro.
>
> >>>Maybe you could explain your top-level use case for this, and the
> >>>general system architecture (which relevant programs are running and
> >>>what their responsibilities are)?
>
> Distro:
> I am working on a product that our company is creating.  It uses an imx8 som
> from Boundary.  The system is not a normal desktop. The DISTRO is created by
> yocto using the gatesgarth branch.  Just recently we were notified that
> Xwayland was working, so I don’t expect we will be removing it just yet.
>
>
> Use case:
> We will have a kiosk-looking desktop.  Some of our pages will have the option
> for the end user to enter text from an on-screen keyboard. Since our display
> will be so small (68.04mm (2.68") x 120.96mm (4.76")), we will have to turn
> our unit sideways to make the keyboard fit.  We have already done this on a
> smaller screen (1.0). On our 1.0 product, we used Segger as our graphics
> library.  Compared to Android, and the like, it seems like rotating the
> screen would be a standard capability.
>
> I believe our compositor (Weston) can do it, transform=90, but to use this
> method, it has to be restarted; causing our gui app to crash and lose all
> entered data. The client probably needs to drive the orientation.
> Considering our gui will likely be in python3/tkinter, I will need some way
> create a page and rotate the display.
>
> I am somewhat limited by the packages available to me in my distro.

> > > >The right way here is to modify Weston to do on-the-fly rotation without 
> > > >a
> > > >restart. You also will want a custom protocol from client to compositor 
> > > >to
> > > >indicate when a client surface wants rotation. This way the compositor 
> > > >can
> > > >correctly rotate the client content and any other on-screen content at 
> > > >the time
> > > > (e.g. keyboard) when that client surface is the active visible one (as 
> > > > a kiosk
> > > >style only one will be active/visible at a time - except for things like
> > > >keyboard etc.). When you switch which surface is the active one then the
> > > >compositor can re-evaluate how to draw on the screen based on what that 
> > > >client
> > > >has requested rotation-wise.
Thank you,
A custom protocol makes sense.

  1.   What’s the best way to communicate with Weston, socket, message, 
function  call?
  2.  How would Weston actually rotate the display, in particular on the fly?
In the Weston documentation, it states that a super-kbd key and middle mouse 
button should rotate the display (if supported).
I’d like to find where that is, as well.

-dwd
--
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

Re: FW: xrandr and xwayland

[Carsten Haitzler]

On Tue, 3 Aug 2021 13:04:11 + David Deyo  said:

> 
> 
> From: David Deyo
> Sent: Monday, August 2, 2021 3:53 PM
> To: Pekka Paalanen
> Subject: RE: xrandr and xwayland
> 
> On Fri, 30 Jul 2021 23:30:38 +0100
> Carsten Haitzler  wrote:
> 
> > On Fri, 30 Jul 2021 16:28:02 + David Deyo  said:
> >
> > No - this is up to the compositor itself to do in its own internal ways. Far
> > too many abuses have happened over the years with xrandr available to any
> > client anywhere. While in theory a wayland compositor could create an
> > extension that works like xrandr, it'd be problematic to make it
> > general-access like xrandr.
> 
> >>>Indeed.
> 
> > >
> > > Hello  everyone,
> > >
> > > I need to rotate  my screen 90 degrees and back to normal in xwayland on
> > > an iMX8 running gatesgarth distro.
> 
> >>>Maybe you could explain your top-level use case for this, and the
> >>>general system architecture (which relevant programs are running and
> >>>what their responsibilities are)?
> 
> Distro:
> I am working on a product that our company is creating.  It uses an imx8 som
> from Boundary.  The system is not a normal desktop. The DISTRO is created by
> yocto using the gatesgarth branch.  Just recently we were notified that
> Xwayland was working, so I don’t expect we will be removing it just yet.
> 
> 
> Use case:
> We will have a kiosk-looking desktop.  Some of our pages will have the option
> for the end user to enter text from an on-screen keyboard. Since our display
> will be so small (68.04mm (2.68") x 120.96mm (4.76")), we will have to turn
> our unit sideways to make the keyboard fit.  We have already done this on a
> smaller screen (1.0). On our 1.0 product, we used Segger as our graphics
> library.  Compared to Android, and the like, it seems like rotating the
> screen would be a standard capability.
> 
> I believe our compositor (Weston) can do it, transform=90, but to use this
> method, it has to be restarted; causing our gui app to crash and lose all
> entered data. The client probably needs to drive the orientation.
> Considering our gui will likely be in python3/tkinter, I will need some way
> create a page and rotate the display.
> 
> I am somewhat limited by the packages available to me in my distro.

The right way here is to modify Weston to do on-the-fly rotation without a
restart. You also will want a custom protocol from client to compositor to
indicate when a client surface wants rotation. This way the compositor can
correctly rotate the client content and any other on-screen content at the time
(e.g. keyboard) when that client surface is the active visible one (as a kiosk
style only one will be active/visible at a time - except for things like
keyboard etc.). When you switch which surface is the active one then the
compositor can re-evaluate how to draw on the screen based on what that client
has requested rotation-wise.

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

FW: xrandr and xwayland

[David Deyo]

From: David Deyo
Sent: Monday, August 2, 2021 3:53 PM
To: Pekka Paalanen
Subject: RE: xrandr and xwayland

On Fri, 30 Jul 2021 23:30:38 +0100
Carsten Haitzler  wrote:

> On Fri, 30 Jul 2021 16:28:02 + David Deyo  said:
>
> No - this is up to the compositor itself to do in its own internal ways. Far
> too many abuses have happened over the years with xrandr available to any
> client anywhere. While in theory a wayland compositor could create an 
> extension
> that works like xrandr, it'd be problematic to make it general-access like
> xrandr.

>>>Indeed.

> >
> > Hello  everyone,
> >
> > I need to rotate  my screen 90 degrees and back to normal in xwayland on an
> > iMX8 running gatesgarth distro.

>>>Maybe you could explain your top-level use case for this, and the
>>>general system architecture (which relevant programs are running and
>>>what their responsibilities are)?

Distro:
I am working on a product that our company is creating.  It uses an imx8 som 
from Boundary.  The system is not a normal desktop.
The DISTRO is created by yocto using the gatesgarth branch.  Just recently we 
were notified that Xwayland was working, so I don’t expect we will be removing 
it just yet.


Use case:
We will have a kiosk-looking desktop.  Some of our pages will have the option 
for the end user to enter text from an on-screen keyboard.
Since our display will be so small (68.04mm (2.68") x 120.96mm (4.76")), we 
will have to turn our unit sideways to make the keyboard fit.  We have already 
done this on a smaller screen (1.0).
On our 1.0 product, we used Segger as our graphics library.  Compared to 
Android, and the like, it seems like rotating the screen would be a standard 
capability.

I believe our compositor (Weston) can do it, transform=90, but to use this 
method, it has to be restarted; causing our gui app to crash and lose all 
entered data.
The client probably needs to drive the orientation.   Considering our gui will 
likely be in python3/tkinter, I will need some way create a page and rotate the 
display.

I am somewhat limited by the packages available to me in my distro.

Thanks,

-dwd


>>>Quite likely the solution will start by removing Xwayland from the
>>>equation, and to have the compositor you use to automatically apply
>>>that rotation when needed, but how to achieve that depends on your use
>>>case. Can the compositor do it all on its own, does the client need to
>>>synchronise to the orientation change, does the client need to drive
>>>the orientation change, etc.

>>>Also sounds like this might not be a normal desktop system you are
>>>working on, which means you have more options on how to design this
>>>than on normal desktop systems with arbitrary applications.


>>>Thanks,
>>>pq

> >
> > Does anyone know if xrandr can be coerced/modified to make rotations work?
> > I’m in the middle of xserver, libX11, libxrandr and xrandr source.
> >
> > How would a client communicating to Xwayland as the xserver request a
> > rotation?  Does Xwayland listen to a unix socket and pass commands on to the
> > kernel?
> >
> > (Thanks Hans,)
> >
> > -dwd
> >  
> > David


 David 
Deyo
[cid:image003.png@01D787B6.7E306F20]

Firmware Engineer
TPI- Tire Profiles
O: 214-396-3063
E:   dd...@tireprofiles.com | W:  
www.tireprofiles.com
A: 3010 Story Rd W, Irving, TX 75038


From: Pekka Paalanen
Sent: Monday, August 2, 2021 3:54 AM
To: David Deyo
Cc: Carsten Haitzler; 
wayland-devel@lists.freedesktop.org
Subject: Re: 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.