@b-aaz I wanted to reach out, and see if you are interested in contributing your ports to a FreeBSD downstream distro? I couldn't find anything on phabricator, or mailing lists for FreeBSD. Will yo...
I need X for a desktop environment I just launched that I have been working on since 2022. Wayland does not support global menus outside of plasma apps as well as many other features that are important for this project.
I think, (though not really up on developments), that this will only be an issue if the existing X is gone. That doesn't seem, despite what RH and other Linuxes that follow it, likely to happen too soon. Even Fedora, which is pretty much a development platform for RH, is keeping X for a while, as near as I can see. There is also Alpine LInux developing Wayback, that, in theory, will allow X based things to run, including window managers. (As far as I know, XWayland allows some X apps, such as rxvt-unicode and xbiff, the only two that I've tried in Wayland, but doesn't allow you to run, say fluxbox on Wayland, to name a window manager that doesn't, as of yet, have a Wayland equivalent. Wayback is pre alpha, as I understand it, but seems like it might be an answer.
This is an opportunity to switch back from libinput (like Xenocara) which is a good thing. The original xorg input drivers worked better and were way less messy. No need to tie our input system to whatever crap Linux is using "this week".
Due to blocking, it could be that the standard xorg drivers didn't get recent media key support. That said, OpenBSD's works way better out of the box than FreeBSD+libinput has ever done, so perhaps we can borrow some of their code here.
I just realized that XLibre with the "original xorg input driver that worked better" mouse driver is not able to use a USB mouse plugged in my laptop, it looks like by default it can use only the integrated touchpad.
Of course this problem doesn't exist with Xorg and "whatever crap Linux is using this week" libinput, you can plug / unplug any pointing devices you want and they work flawlessly.
I just realized that XLibre with the "original xorg input driver that worked better" mouse driver is not able to use a USB mouse plugged in my laptop, it looks like by default it can use only the integrated touchpad.
Strange. Works for me (could be that my BIOS/EFI usb/ps2 emulation has kicked in). And I don't see any issues on the Xenocara mailing list. It could be you are using a neglected version of the driver? Were you involved in open-source operating systems back when the original drivers were the default on FreeBSD? What did you think of them?
Of course this problem doesn't exist with Xorg and "whatever crap Linux is using this week" libinput, you can plug / unplug any pointing devices you want and they work flawlessly.
Once libinput is deprecated, then the proper Xorg/Xlibre input driver will likely be less neglected and better maintained.
For giggles, try to set the mouse sensitivity. As a hint, the standard xset m is not functional with libinput. At one point the latter was so broken people had to create a Coordinate Transformation Matrix. Yuck! Much of my day job involves programming linear algebra. I certainly don't want to be doing more of it just to change my mouse settings...
That indeed worked... sort of. I have to report a regression, my multimedia keyboard does not work with xlibre, no media keys, no TouchPad and so on. Only basic keys work.
Rollback to xorg - > all working perfectly. Any ideas?
[edit] just to make it clear: I reported it only to document my issue, I'm not asking for help of course, I know that things may not work at this stage.
This is fixed now.
It was caused by a commit mistakenly disabling udev in a silent way for FreeBSD in the meson.build.
I should watch the stage-qa's cries more closely ... .
Sent a PR to the upstream too.
This is fixed now.
It was caused by a commit mistakenly disabling udev in a silent way for FreeBSD in the meson.build.
I should watch the stage-qa's cries more closely ... .
Sent a PR to the upstream too.
...and of course it works fine, good job. There's a small nitpick: in your repository there's no "xlibre" meta-package to replace the "xorg" meta-package. So now after installing xlibre-server and xlibre-drivers I have tons of packages showing up when I issue "pkg autoremove".
That is interesting. Was there a reason why the dozens of others were not considered commit worthy? Or did someone try to pull the life support plug on xorg?
They are committed, they are in the master branch. The next actual release would be 25.1, and it would contain those patches, but they have decided not to make an actual release for 4 years.
What seems most likely to me is both that a lot of Weigelt's patches are crap, and that Freedesktop has been suppressing fixes to Xorg in order to drive Wayland adoption.
I wouldn't call them "crap", but sure, I would agree some of Weigelt's patches could have used more care, but that's why people work on teams, so the weaknesses of some team members are compensated with the strengths of other members. Weigelt works really fast, I work very carefully, so I can review his patches and point out potential issues. Nobody needs to be the full package while working on a team.
FWIW, I'm still using XLibre and I can say that I haven't encountered any issue since the libinput issue was solved. I replaced GNOME with Cinnamon 6.4.10 from ports (because I don't need a display manager and GNOME is not meant to be used without GDM) and it works really well.
...and of course it works fine, good job. There's a small nitpick: in your repository there's no "xlibre" meta-package to replace the "xorg" meta-package. So now after installing xlibre-server and xlibre-drivers I have tons of packages showing up when I issue "pkg autoremove".
@b-aaz I wanted to reach out, and see if you are interested in contributing your ports to a FreeBSD downstream distro? I couldn't find anything on phabricator, or mailing lists for FreeBSD. Will yo...
From my comment in this issue regarding working on XLibre in GhostBSD ports that I thought needed to be reposted here too, for more ideas:
I'm kinda stuck on this one... .
I have started working on the ports outside of my tree that depend on xorg-server. pkg rquery %rn xorg-server on the FreeBSD repos list these:
Now these ports should be modified to be "installable" when xlibre-server is installed while not making them unavailable to xorg-server users too.
The solutions that I see are:
Making 2 ports from each of these one with a dependency on xlibre-server, one on xorg-server.
Making them have a radio option for dependency on xlibre-server or xorg-server.
Non of the above options look really good to me. Particularly when the overarching meta-ports also come into the play. but maybe I'm over-complicating all this and there is a simpler option.
From my comment in this issue regarding working on XLibre in GhostBSD ports that I thought needed to be reposted here too, for more ideas:
I'm kinda stuck on this one... .
I have started working on the ports outside of my tree that depend on xorg-server. pkg rquery %rn xorg-server on the FreeBSD repos list these:
Now these ports should be modified to be "installable" when xlibre-server is installed while not making them unavailable to xorg-server users too.
The solutions that I see are:
Making 2 ports from each of these one with a dependency on xlibre-server, one on xorg-server.
Making them have a radio option for dependency on xlibre-server or xorg-server.
Non of the above options look really good to me. Particularly when the overarching meta-ports also come into the play. but maybe I'm over-complicating all this and there is a simpler option.
This way, for example, if Mk/Uses/xorg.mk considers argument xorg-server to be xlibre-server if DEFAULT_VERSIONS+= xlibre is set in /etc/make.conf, USES= xorg and USE_XORG= xorg-server are set in each ports makefile results pulling xlibre-server instead.
Not sure how difficult it is, though, but for example, Mk/Uses/jpeg.mk chooses graphics/jpeg-turbo or graphics/mozjpeg depending on its argument. There should be more complex but more informative one.
Option 1 (modify each ports) should be no-go.
When ports switched from XFree86 (xf86) to X.org (xorg), a mechanism to choose which implementation should be used is implemented (now removed). Something like it (using USES which didn't yet existed at the moment) would be the way to go.
This way, for example, if Mk/Uses/xorg.mk considers argument xorg-server to be xlibre-server if DEFAULT_VERSIONS+= xlibre is set in /etc/make.conf, USES= xorg and USE_XORG= xorg-server are set in each ports makefile results pulling xlibre-server instead.
Not sure how difficult it is, though, but for example, Mk/Uses/jpeg.mk chooses graphics/jpeg-turbo or graphics/mozjpeg depending on its argument. There should be more complex but more informative one.
Well the X.Org xf86 drivers shouldn't depend on XLibre, this method makes everything depend on XLibre, We also have the xorg and xorg-minimal metaports that would break.
When FreeBSD ports switched from XFree86 to Xorg gradually (not at once), xf86 drivers remained as-was as the PORTNAME shows. Why not impossible this time?
When FreeBSD ports switched from XFree86 to Xorg gradually (not at once), xf86 drivers remained as-was as the PORTNAME shows. Why not impossible this time?
So just limited, actually forked part are needed to be handled "conditionally".
For example, ports Makefile of x11/nvidia-driver and x11/linux-nvidia-libs has a bunch of conditionals to support multiple slave (child) ports. And *.mk directly under Mk/ and Mk/Uses/ are Makefiles, too.
baaz - I suggest you speak with the KDE maintainers because pkg install kde brings in xorg-server and thus it's impossible to use your packages with KDE.
baaz - I suggest you speak with the KDE maintainers because pkg install kde brings in xorg-server and thus it's impossible to use your packages with KDE.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
github.com
.
