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. Thanks, -- David Cantrell <[email protected]> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
