Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2023-01-19 at 19:46 +1000, Peter Hutterer wrote:
> 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


Thanks for opening the BZs and creating these settings. So, this means
at least our use case of SSH terminals with the occasional X client
and/or copy & paste via X at least has a workaround. I'm still
skeptical of the cost to benefit ratio here though. On the LWN article
about this someone mentioned that there are also Big Endian
oscilloscopes that are used with X remoting and I suspect there are
other industrial appliances too. Personally I think with X11 more or
less in maintenance mode for decades to come the likelihood of new bugs
in this area is somewhat low even with few users. Together with X and
especially X remoting becoming more and more a niche thing itself
keeping those niches where it is still needed working out of the box is
a worthwhile effort. But in the end I'm not an expert on this and I'll
trust the judgement of the experts.

Thanks,
Niklas
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux