On Fri, Jan 06, 2023 at 11:13:14AM +1000, Peter Hutterer wrote: > On Thu, Jan 05, 2023 at 08:24:21AM -0500, Stephen Smoogen wrote: > > On Thu, 5 Jan 2023 at 08:20, David Cantrell <dcantrell@xxxxxxxxxx> wrote: > > > > > On Thu, Jan 05, 2023 at 11:10:20AM +1000, Peter Hutterer wrote: > > > > On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote: > > > > [...] > > > > > > So I guess this means no remoting into ppc64 or s390x machines from > > > > > > x86_64 or ppc64le machines without a configuration tweak? > > > > > > > > > > We don't have ppc64 builds anymore and I don't know the last release > > > we had > > > > > that was ppc64, but it was a long time ago now. All current POWER > > > systems are > > > > > ppc64le. > > > > > > > > > > And everything else we have as primary or alternative architectures is > > > little > > > > > endian, except s390x. I do view this as a risk for s390x because of > > > all the > > > > > architectures we build for, this one is the most difficult to use > > > graphically. > > > > > Exporting your display is still the convenient method for this > > > platform. > > > > > > > > > > Given that this change proposal affects default behavior, I don't see a > > > > > problem with it. s390x users can drop the configuration change in > > > xorg.conf.d > > > > > to regain the functionality. If that can be conditionally enabled for > > > s390x > > > > > at package build time, that might make things easier (but wouldn't you > > > need to > > > > > make the change on both the s390x host and your non-s390x > > > workstation?). > > > > > > > > The X protocol works that the first byte of the connection request is a > > > > either 'l' or 'B', telling the server that the client is little or Big > > > > endian. The client has no information on the server's endianess. > > > > > > > > This means the configuration needs to be done wherever your X server > > > > runs, so the (little-endian) thing you're sitting in front of. Which is > > > > also why compile-time defaults are difficult, at compile time we cannot > > > > know that eventually you may want to connect from an s390x. > > > > > > Reasonable. The runtime configuration change I can make locally to allow > > > me > > > to run X programs on an s390x and display them locally is sufficient for > > > me. > > > > > > > Wasn't there a concern that you can do this if you are running a desktop > > with X, but if you are using Xwayland it isn't easy (or maybe possible) as > > the configuration to do that was either hardcoded or not fully documented > > on how to do that? > > > > From Peter Hutterer <peter.hutterer@xxxxxxxxx> earlier: > > ``` > > but you don't necessarily have > > access to how Xwayland is started (mutter certainly is hard-coded). > > ``` > > Correct, the Wayland compositor is responsible for starting up XWayland > and that's not always configurable. I've filed bugs for mutter, kwin and > wlroots so the developers are aware and that should cover the majority > of Wayland use-cases once fixed. just a minor follow-up: mutter has that feature merged now for GNOME 43 [1] so a once-off gsettings call should do the trick there: $ gsettings set org.gnome.mutter.wayland xwayland-allow-byte-swapped-clients true Cheers, Peter [1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2785 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
