Re: xserver and splitting ultra-wide monitors
Hello Keith, I'm glad that you have a look on this. I first tried to contact you directly using the intel address in https://gitlab.freedesktop.org/xorg/doc/xorg-docs/-/blob/master/MAINTAINERS but this seems not be valid anymore. I absolutely agree with what you wrote about the user-specified vs automatically created monitors. But the code I'd like to remove does not deal with these. It's only about having 2 monitors on one output. https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/randr/rrmonitor.c Lines 526-529 should not be touched. If a monitor with the same name will be added elsewhere, the existing should be removed (avoids to have multiple monitors with the same name) Lines 537-551 sould be removed. It's only about having not more than one monitor on one output. I removed these on my local xserver and did the following test: # xrandr --listmonitors Monitors: 1 0: +*DisplayPort-1 3440/820x1440/346+0+0 DisplayPort-1 # xrandr --setmonitor VIRTUAL-LEFT 1720/0x1440/1+0+0 DisplayPort-1 # xrandr --listmonitors Monitors: 1 0: VIRTUAL-LEFT 1720/0x1440/1+0+0 DisplayPort-1 # xrandr --setmonitor VIRTUAL-RIGHT 1720/0x1440/1+1720+0 DisplayPort-1 # xrandr --listmonitors Monitors: 2 0: VIRTUAL-LEFT 1720/0x1440/1+0+0 DisplayPort-1 1: VIRTUAL-RIGHT 1720/0x1440/1+1720+0 DisplayPort-1 # xrandr --delmonitor VIRTUAL-LEFT # xrandr --delmonitor VIRTUAL-RIGHT # xrandr --listmonitors Monitors: 1 0: +*DisplayPort-1 3440/820x1440/346+0+0 DisplayPort-1 As you can see, all works fine, I can create 2 monitors on the one output and the handling of the auto-generated monitor still works as expected. When I do # xrandr --fb 3440x1441; xrandr --fb 3440x1440 afterwards (this triggers an update to the display manager), I can use both monitors on xfce (at least I can drag windows over both and maximize on the second but that's a different issue within gtk). Kind regards, Michael. Am 29.09.22 um 22:41 schrieb Keith Packard: Michael Wyraz writes: For the second monitor, the output must be set to "none" which is obviously wrong since it is connected to a device. The reason why it is set to "none" is some code in xserver that removes an monitor if another one is added to the same output: That's actually required in the RandR spec: For each output in 'info.outputs, each one is removed from all pre-existing Monitors. If removing the output causes the list of outputs for that Monitor to become empty, then that Monitor will be deleted as if RRDeleteMonitor were called. The notion of splitting one physical output into multiple virtual monitors was not considered when this extension was defined, which is why it doesn't work. I don't see any particular reason for *not* supporting your use case. However, there are subtleties here. We want to remove any automatically created 'Monitor' objects when mapping user-specified monitors to them, and we want to re-generate automatically generated 'Monitors' when all virtual monitors associated with an output are removed. I think what we want is: * If no user-specified Monitors map to a particular Output, then automatically create a Monitor for that Output * If any user-specified Monitors map to a particular Output, then remove the automatically generated Monitor for that Output. In the current spec, there's no real separation between user-specified and automatically-generated Monitors, I think that would be necessary to make this work?
Re: xserver and splitting ultra-wide monitors
Michael Wyraz writes: > For the second monitor, the output must be set to "none" which is > obviously wrong since it is connected to a device. The reason why it is > set to "none" is some code in xserver that removes an monitor if another > one is added to the same output: That's actually required in the RandR spec: For each output in 'info.outputs, each one is removed from all pre-existing Monitors. If removing the output causes the list of outputs for that Monitor to become empty, then that Monitor will be deleted as if RRDeleteMonitor were called. The notion of splitting one physical output into multiple virtual monitors was not considered when this extension was defined, which is why it doesn't work. I don't see any particular reason for *not* supporting your use case. However, there are subtleties here. We want to remove any automatically created 'Monitor' objects when mapping user-specified monitors to them, and we want to re-generate automatically generated 'Monitors' when all virtual monitors associated with an output are removed. I think what we want is: * If no user-specified Monitors map to a particular Output, then automatically create a Monitor for that Output * If any user-specified Monitors map to a particular Output, then remove the automatically generated Monitor for that Output. In the current spec, there's no real separation between user-specified and automatically-generated Monitors, I think that would be necessary to make this work? -- -keith signature.asc Description: PGP signature
Re: [Xcb] pthread stubs in libX11 vs. libxcb
Alan Coopersmith writes: > I'm not familiar with the runtime linkers on all platforms, but I know at > least > on Solaris, lazy loading won't load the library until the first reference to > it > is made (or a search needs to be made for a reference that doesn't have direct > binding information to record what library to load for it). Ah. That makes sense. I have the feeling that lots of us are planning for or actually using non-lazy loading as that lets the relocation tables be marked read-only after startup (-z relro -z now in the gnu linker). > I also don't know if the ordering between library loading and init section > execution is well defined. That's a good point -- with lazy loading, if the other libraries aren't even loaded until first used, then it seems unlikely that their init sections are invoked before then. -- -keith signature.asc Description: PGP signature
Re: [Xcb] pthread stubs in libX11 vs. libxcb
Hi, Am 29.09.22 um 06:27 schrieb Keith Packard: Alan Coopersmith writes: Does anyone disagree? Yeah, synchronizing with xcb seems 'obviously right. The only question I've got is that in 2022, should xcb ever use stubs for the thread functions? No, it shouldn't. That's why since 2017, pthread-stub just links against pthread. It only does not do that if libc already includes the necessary stubs. See https://gitlab.freedesktop.org/xorg/lib/pthread-stubs/-/commit/8340ebd656c7e1a5b6d31170c1f3c87df043e793 Cheers, Uli -- "Do you know that books smell like nutmeg or some spice from a foreign land?" -- Faber in Fahrenheit 451
Re: [Xcb] pthread stubs in libX11 vs. libxcb
Hi, Am 29.09.22 um 02:29 schrieb Alan Coopersmith: [...] Which in hindsight, sounds a lot like that bug 162 linked above - the libX11 xlib_ctor would call XInitThreads() at library load time, which would use the stubs to fake initializing the mutexes, and then libxcb would be loaded later (likely when XOpenDisplay() is called) pulling in the real pthreads library, Why is libxcb only loaded later? I would expect that by the time XInitThreads() can be called, the dynamic linker has at least loaded all dependent libraries. So, if libxcb links against libpthread, then libpthread should already be loaded at this time. Is this thinking wrong? Cheers, Uli -- "Do you know that books smell like nutmeg or some spice from a foreign land?" -- Faber in Fahrenheit 451
Information about XDC 2022 - next week!
Hi folks, We are excited to welcome you in person to the 2022 X.Org Developers Conference, held in conjunction with WineConf and FOSS XR conference. The conference will start officially on Tuesday morning, October 4th. The program is here: https://indico.freedesktop.org/event/2/timetable/#all.detailed The official events start at 8:30 am, but we will have coffee and pastries available from 7:30 on Tuesday and 8 on Wednesday and Thursday. We expect everyone attending to be vaccinated and to be respectful of people that are trying to avoid catching COVID. Masks are mandatory, except when presenting or eating. A small number of us will gather informally at Brit’s Pub, starting at around 4:00 pm on Monday, October 3rd. We’ll try to have a table with some sort of a sign, and folks can connect, have a drink, and then perhaps group up to explore alternate food. Note that if the weather is nice, we may be up on the roof, so explore far to find us. We will be on the Minneapolis campus of St. Thomas, which is a mildly confusing campus. We have given instructions and a picture to guide you here: https://indico.freedesktop.org/event/2/page/10-attending-xdc-wineconf-foss-xr We are working on the remote experience, and expect to have streaming of all events available. The above page will have those details just as soon as they are finalized. We have a page of instructions for folks that will be presenting: https://indico.freedesktop.org/event/2/page/18-speaker-instructions We are also excited to announce the happy hour taking place on Wednesday, from 6:00 pm until 8:00 pm. The hope is that all three projects can mingle and socialize and enjoy the return of in person meetings. Also, this year we plan to adopt the Wine strategy of using a deliberate Matrix chat room just for the conference. Matrix has a variety of apps, and Element, the default one is easy to configure on many devices, including mobile phones. The link to that channel is here: https://matrix.to/#/#xdc-wineconf-fossxr-2022:matrix.org We find the chat channel a good place to learn what restaurants and bars are chosen, and just a good way to track the social aspects of the conference. We look forward to seeing you next week! Cheers, Jeremy
Re: [Xcb] pthread stubs in libX11 vs. libxcb
On 9/29/22 08:44, Uli Schlachter wrote: Hi, Am 29.09.22 um 02:29 schrieb Alan Coopersmith: [...] Which in hindsight, sounds a lot like that bug 162 linked above - the libX11 xlib_ctor would call XInitThreads() at library load time, which would use the stubs to fake initializing the mutexes, and then libxcb would be loaded later (likely when XOpenDisplay() is called) pulling in the real pthreads library, Why is libxcb only loaded later? I would expect that by the time XInitThreads() can be called, the dynamic linker has at least loaded all dependent libraries. So, if libxcb links against libpthread, then libpthread should already be loaded at this time. Is this thinking wrong? I'm not familiar with the runtime linkers on all platforms, but I know at least on Solaris, lazy loading won't load the library until the first reference to it is made (or a search needs to be made for a reference that doesn't have direct binding information to record what library to load for it). I also don't know if the ordering between library loading and init section execution is well defined. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
xserver and splitting ultra-wide monitors
Hello Xorg developers, about a year ago I investigated in how to split ultra-wide monitors on linux into multiple virtual monitors. While this is basically possible with xserver and xrandr, a combination of different issues stops from using this feature on most desktops. Unfortunately, the issues still exist. I'd like to start another attempt to get this finally work. The first step would be xserver and xrandr. It is easily possible to split a monitor with xrandr into two: xrandr --setmonitor VIRTUAL-LEFT 2560/0x1440/1+0+0 DP-4 xrandr --setmonitor VIRTUAL-RIGHT 2560/1x1440/1+2560+0 none For the second monitor, the output must be set to "none" which is obviously wrong since it is connected to a device. The reason why it is set to "none" is some code in xserver that removes an monitor if another one is added to the same output: https://gitlab.freedesktop.org/mwyraz/xserver/-/merge_requests/1/diffs I believe, this code should be removed entirely for two reasons. The first is, that two virtual monitors on one output is perfectly valid. The other is, that the function is about adding monitor. It should not be silently delete another monitor. If there is a reason to delete one monitor if another is added, such functionality should be part of the tooling (like in xrandr) - this would also allow to implement different behaviours (e.g. a warning or an option to enforce to have multiple monitors on one output). What do you think about this? Could you help to get this solved? If so and this could be fixed, my next step would be to address the related issue in gtk (https://gitlab.gnome.org/GNOME/gtk/-/issues/2013) so that gtk based desktops would properly work on a splitted ultra-wide screen. Kind regards, Michael.
