X11Libre
incorporate drivers into xserver tree
Can you provide the motivation for doing this?
making maintenance easier - we don't need to care about which driver version fits to which xserver version anymore.
Can you provide the motivation for doing this?
making maintenance easier - we don't need to care about which driver version fits to which xserver version anymore.
Do you plan to add all drivers or only the ones currently added? This will also force distros to build with all drivers since users wont be able to otherwise use drivers selectively
Can you provide the motivation for doing this?
making maintenance easier - we don't need to care about which driver version fits to which xserver version anymore.
Do you plan to add all drivers or only the ones currently added? This will also force distros to build with all drivers since users wont be able to otherwise use drivers selectively
If I've got it right, this should just make a bunch of driver.so files, and as long as XLibre boots with those missing, distros should be able to package them in different packages.
I don't think this is a good idea. Right now, all drivers other than modesetting are out of tree. This means that people can write drivers for the X server without needing to add it to the X server tree. Putting all drivers in-tree means that anyone who wants to write a driver needs to make a pull request here and add it to the X server tree, which I don't think is a good idea.
Do you plan to add all drivers or only the ones currently added? This will also force distros to build with all drivers since users wont be able to otherwise use drivers selectively
Distros can opt-in/out as they wish and they can put them into separate binary packages.
The benefit for us is we can easily do refactoring without having to care which driver versions match which xserver versions. Similar like in the kernel. Taking care of ABI stability is a tedious and complicated thing to do - I'd like to keep that out of the way (at least for anything that doesn't affect the nvidia proprietary driver).
Right now, all drivers other than modesetting are out of tree. This means that people can write drivers for the X server without needing to add it to the X server tree.
They still can. But it's not a good idea to do so - it's just causing unnecessary trouble for both sides. Same reason why the Linux kernel has no public driver ABI.
Putting all drivers in-tree means that anyone who wants to write a driver needs to make a pull request here and add it to the X server tree, which I don't think is a good idea.
Anybody actually planning to write new drivers ?
If I've got it right, this should just make a bunch of
driver.sofiles, and as long as XLibre boots with those missing, distros should be able to package them in different packages.
Yes, of course. All that's changing is they're coming from one source tree now - and so having the same versions and lifecycle (the only thing distros need to care of is setting package dependencies accordingly, so one always getting the same driver version as xserver version).
Can you provide the motivation for doing this?
making maintenance easier - we don't need to care about which driver version fits to which xserver version anymore.
Do you plan to add all drivers or only the ones currently added? This will also force distros to build with all drivers since users wont be able to otherwise use drivers selectively
for distros maintainers convenience can be fixed with meson option build drivers only and ability to make driver install separately (like ninja magic_here_install xf86-video-fbdev)
for distros maintainers convenience can be fixed with meson option build drivers only and ability to make driver install separately (like ninja magic_here_install xf86-video-fbdev)
For the self-compiling distros (eg. Gentoo) it would be a matter of useflag (or however the distro calls it), which is translated to corresponding meson options. IMHO, this actually makes more sense here, since Xserver isn't the only one needing GPU-specific drivers/settings. And usually one wants to configure this globally.
For the binary-packaged distros, it's just a matter of splitting the install tree into separate binary packages - which already is a very common approach, and packaging toolchains have their convenient ways to do this.
Yes, distros have a little bit extra work with this change, but it's really not much.
For the self-compiling distros (eg. Gentoo) it would be a matter of useflag (or however the distro calls it), which is translated to corresponding meson options. IMHO, this actually makes more sense here, since Xserver isn't the only one needing GPU-specific drivers/settings. And usually one wants to configure this globally.
For the binary-packaged distros, it's just a matter of splitting the install tree into separate binary packages - which already is a very common approach, and packaging toolchains have their convenient ways to do this.
Yes, distros have a little bit extra work with this change, but it's really not much.
Sorry i felt like making noise - currently you can build xserver repository with everything disabled.
I don't know if it should be separate issue, when you building only driver meson setup build -Dxorg=false -Dxnest=false -Dxephyr=false -Dxvfb=false -Dxf86-video-fbdev=true -Dprefix=/tmp/xlibre
xserver 25.0.0.5
DDX
Xorg : NO
Xnest : NO
Xvfb : NO
Xwin : NO
Xquartz : NO
User defined options
prefix : /tmp/xlibre
xephyr : false
xf86-video-fbdev: true
xnest : false
xorg : false
xvfb : false
Found ninja-1.9.0.git.kitware.dyndep-1.jobserver-1 at /usr/bin/ninja
user@pc ~/xserver $ cd build/
user@pc ~/xserver/build $ ninja install
[382/383] Installing files.
Installing ..path../xserver/build/man/Xserver.1 to /tmp/xlibre/share/man/man1
Installing ..path../xserver/dix/protocol.txt to /tmp/xlibre/lib64/xorg
Extra protocol.txt and Xserver.1 are installed.
Putting all drivers in-tree means that anyone who wants to write a driver needs to make a pull request here and add it to the X server tree, which I don't think is a good idea.
Anybody actually planning to write new drivers ?
There are third party Xorg drivers. Most notably nvidia and fbturbo, but I'm sure there are others.
@metux Could you please stop working so chaotically. There are currently 72 open pull requests and 70 issues open. We have users reporting serious regressions and breakages, making pr's for those regressions, and making pr's for various improvements. A lot of these require input from you.
Meanwhile, you are making lots of large and unrelated pr's, like this one where there are 40k lines changed for no apparent benefit other than cleaner code, which is a subjective standard.
For example, we already bundled libXtrans with the promise that 'it will eventually lead to cleaner code', yet I didn't see any work being done of that front.
Instead of fixing regressions and making improvements, we're making pr's like this one where we just move code around for no functional benefit.
Also, pr's like this have the potential to introduce bugs. I've spent days fixing regressions and helping other users with theirs, and I'm pretty sure you and others did the same.
On the gentoo forums, users are complaining that the IgnoreAbi option is still needed on nvidia proprietary, and it's breaking their setups. There is a pr for this, but instead of working on that, which would actually benefit users, we're making 40k line pr's bundling ddx drivers.
Glamor acceleration is broken on amd hw, and there is a pr for that, which is waiting for your review: https://github.com/X11Libre/xf86-video-ati/pull/4 Instead of that, we're spending time on this.
I could keep going with examples of issues/pr's waiting for your attention.
Please first help fix regressions, bugfixes, and followups of other changes that were added in preparation for future work.
The way I see this, you keep making changes that by themselves don't really make much sense, while saying that they are in preparation for some other improvements to the X server that seemingly never come.
Meanwhile, you are making lots of large and unrelated pr's, like this one where there are 40k lines changed for no apparent benefit other than cleaner code, which is a subjective standard.
@metux, please stop We're at 120k lines now, and you're now making code changes to drivers like chips and geode, which I'm quite sure you didn't test.
@stefan11111 @metux
Right now, all drivers other than modesetting are out of tree. This means that people can write drivers for the X server without needing to add it to the X server tree.
They still can. But it's not a good idea to do so - it's just causing unnecessary trouble for both sides. Same reason why the Linux kernel has no public driver ABI.
There is a least one "out-of-tree" driver called rxrbln/xf86-video-ps3. It was asked whether we want to adopt it in PS3 driver · X11Libre · Discussion #196.
Could we add to xserver tree one by one only those forked drivers that have undergone refactoring, codebase cleaning, bugfixing and are reviewed by users as stable and mostly problem-free?
Otherwise it will be a heavy burden on XLibre reputation and will allow anyone to criticize overall quality of XLibre code.
@ONykyf
Could we add to xserver tree one by one only those forked drivers that have undergone refactoring, codebase cleaning, bugfixing and are reviewed by users as stable and mostly problem-free?
Otherwise it will be a heavy burden on XLibre reputation and will allow anyone to criticize overall quality of XLibre code.
+1 That's a good point.
There is a least one "out-of-tree" driver called rxrbln/xf86-video-ps3. It was asked whether we want to adopt it in PS3 driver · X11Libre · Discussion #196.
If anybody's going to maintain and test it, I'd be happy to add it. (don't own that HW, so can't offer much help).
Could we add to xserver tree one by one only those forked drivers that have undergone refactoring, codebase cleaning, bugfixing and are reviewed by users as stable and mostly problem-free?
Sure. This PR is only a draft for discussing the general idea. And I'd start with the most rarely used ones - and as long as we only have Linux CI runners only those building on Linux.
In the very long run I'd like to see all of those we're maintaining (including potentially new ones like the currently orphaned fbturbo) to go in-tree, so we can reduce public ABI surface to only what's needed for the proprietary nvidia driver (as long as we need it).
By the way, it might make sense to start with some input drivers, eg. classic keyboard and mouse (not evdev/libinput-based) - then we could factor out common pieces with upcoming Xfbdev into some library.
One thing we obviously have to do is clear communication to distros, which might split out drivers into separate binary packages: those always need to be exactly the same version like the Xserver (already the case for modesetting and inputtest) - so they can fix up their dependencies accordingly.
In the very long run I'd like to see all of those we're maintaining go in-tree
Perhaps I just don't see the benefit, but this looks to me like we're trying to move back to XFree86 where everything was tangled together and monolithic.
like the currently orphaned fbturbo
fbturbo is still maintained, though not actively, and it doesn't build with Xlibre, only Xorg: https://github.com/KenjiBrown/xf86-video-fbturbo/tree/aarch64-gentoo
so we can reduce public ABI surface to only what's needed for the proprietary nvidia driver (as long as we need it).
Perhaps we could one day get modesetting to be at least as good as the proprietary nvidia ddx. Until then, we are stuck with it. As a side note, I get why nvidia would want to keep their kernel module proprietary, but why also make the ddx driver proprietary?
In the very long run I'd like to see all of those we're maintaining go in-tree
Perhaps I just don't see the benefit, but this looks to me like we're trying to move back to XFree86 where everything was tangled together and monolithic.
For the drivers, yes. IMHO they should have never been split out (in constrast to libraries and extra programs). The problem is: there just is no actual stable ABI that's designed well enough for actually being stable over long time. (if we wanted to do this, we'd need a lot of resources and would end up with windows-like bloat)
Drivers and Xserver itself are very tightly interconnected (and people did so many weird hacks in their drivers instead of just extending / refactoring the API/ABI), that it's just easier to have them inside the Xserver tree, sharing the same lifecycle.
like the currently orphaned fbturbo
fbturbo is still maintained, though not actively, and it doesn't build with Xlibre, only Xorg: https://github.com/KenjiBrown/xf86-video-fbturbo/tree/aarch64-gentoo
Ok, if anybody likes to maintain it, I'd be happy to create a repo for it.
so we can reduce public ABI surface to only what's needed for the proprietary nvidia driver (as long as we need it).
Perhaps we could one day get modesetting to be at least as good as the proprietary nvidia ddx. Until then, we are stuck with it.
Yes, unfortunately. But this doesn't mean we should keep similar problems with the opensource drivers.
As a side note, I get why nvidia would want to keep their kernel module proprietary, but why also make the ddx driver proprietary?
Thats the 1M$ question. Maybe @aaronp24 can answer this ?
Replicating https://github.com/X11Libre/misc/discussions/207#discussioncomment-13879255
The DDX drivers are not meant to be useful outside an X server. It makes sense to keep them in a same tree. However this move will increase the codebase and will require developers with that specific hardware to test. (Incidentally, I want to buy a jailbroken PS3.)
For source-based distros, we can provide flags like -Dddx_list="matrox ati i910 playstation3 . . .".
There is an extra problem to deal, however. Is it possible to install each DDX in its own directory? For distros like Guix, Gobo and NixOS this is very important.
I kindly ask you to bring the discussion back to Incorporating drivers into Xserver tree · X11Libre · Discussion #207.
@metux
Sure. This PR is only a draft for discussing the general idea.
The discussion should have taken place in Incorporating drivers into Xserver tree · X11Libre · Discussion #207 before and not after so much code has been moved.
To cut a long story short: I am against these changes as long as their advantages and disadvantages have not been discussed within the core team. And so far, this discussion has not taken place. I will write more about this later.
Metux: Thats the 1M$ question. Maybe @aaronp24 can answer this ?
If you truly think any Nvidia employee will answer you now or in the future, then that's wishful thinking. It was hostile Nvidia's leverage that caused the massive reverts in Xorg repo. That aaron guy was glad and thrown you under the bus. Here: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2017#note_2956688 It's just waste of time.
I absolutely disagree with this change.
This would be a HUGE task on all port maintainers that maintain XLibre ports across different OSs. It would mix the issue trackers and commit logs of all these drivers with the xserver one. And force people to fetch a ton of code that they would not need.
When we build drivers in-tree rather than loading them as external modules brings us to parity with similar conventions with wayland not having external modules. Embedding drivers at compile time reduces runtime overhead by eliminating dynamic module lookups and linkage jumps, which can noticeably improve input/output latency. It also streamlines packaging and installation. you can enable or disable individual drivers directly through Meson build options instead of managing separate module files.
Great changes keeping external modules is needless clutter we could easily just maintain them from inside xserver instead allowing for managing scope more easily.
