Skip to main content
Topic: Xlibre release 25.0.0.0 now available for testing (Read 25091 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Xlibre release 25.0.0.0 now available for testing

Reply #75

Maybe there is some issue between LightDM and Xlibre.


FYI, I am using lightdm & xlibre. They work fine. Haven't seen any issues.

Re: Xlibre release 25.0.0.0 now available for testing

Reply #76
I installed the xlibre iso with runit to test a few things. I installed in a qemu VM and then copied that system to a couple different places.  Added gremlins and updated to get latest version (25.0.0.4-1)

copied to thinkpad:
x11vnc works. I tried it in both directions (as server and as client). It acts just like I expected it to act.
x11 forwarding over ssh didn't work until I edited /etc/ssh/sshd_config to allow it
Watching 1080p video works.
I didn't test any of my favorite games - I assume freecell works fine. :P

copied to a directory on host system:
xserver-xephyr works. I can chroot the copy and get a graphical session.

copied to crappy usb stick:
x11vnc worked (both directions)
x11 forwarding worked without changing the ssh config.
xserver-xephyr didn't work. When I replaced xlibre with xorg, it still didn't work and I managed to render that system unbootable. I'm blaming the usb stick for that.

Nice work! I'll keep playing with it.

Re: Xlibre release 25.0.0.0 now available for testing

Reply #77
Me again. I did everything what Shoun said, here's the results.

After reinstalling xlibre, I also put xorg.conf in its place again.

Code: [Select]
Section "Device"
    Identifier "AMD"
    Driver      "modesetting"
    Option "TearFree" "False"
EndSection

I also made sure to remove all xf86-video packages except for the amdgpu one:

Code: [Select]
$ pacman -Qs xlibre
local/xlibre-xf86-input-elographics 1.4.4.1-1.1 (xlibre-drivers)
    XLibre fork of X.Org Elographics TouchScreen input driver
local/xlibre-xf86-input-evdev 2.11.0.1-1.2 (xlibre-drivers)
    XLibre fork of X.Org evdev input driver
local/xlibre-xf86-input-libinput 1.5.0.1-1.3 (xlibre-drivers)
    XLibre fork of the generic input driver for the X.Org server based on libinput
local/xlibre-xf86-input-synaptics 1.10.0.1-1.1 (xlibre-drivers)
    XLibre fork of X.Org Synaptics driver for notebook touchpads
local/xlibre-xf86-input-vmmouse 13.2.0.1-1.1 (xlibre-drivers)
    XLibre fork of X.Org VMWare Mouse input driver
local/xlibre-xf86-input-void 1.4.2.1-1.1 (xlibre-drivers)
    XLibre fork of X.Org void input driver
local/xlibre-xf86-input-wacom 1.2.3.1-1.7 (xlibre-drivers)
    XLibre fork of X.Org Wacom tablet driver
local/xlibre-xf86-video-amdgpu 23.0.0.1-1.1 (xlibre-drivers)
    XLibre fork of X.Org amdgpu video driver
local/xlibre-xserver 25.0.0.4-1 (xlibre)
    XLibre fork of X.Org X server
local/xlibre-xserver-common 25.0.0.4-1 (xlibre)
    XLibre fork of X.Org Xorg server common files
local/xlibre-xserver-devel 25.0.0.4-1 (xlibre)
    XLibre fork of X.Org development files for the X.Org X server
local/xlibre-xserver-xephyr 25.0.0.4-1 (xlibre)
    XLibre fork of X.Org nested X server that runs as an X application
local/xlibre-xserver-xnest 25.0.0.4-1 (xlibre)
    XLibre fork of X.Org nested X server that runs as an X application
local/xlibre-xserver-xvfb 25.0.0.4-1 (xlibre)
    XLibre fork of X.Org virtual framebuffer X server

Now, at first glance there is one big difference, the output of xrandr looks different (compared to the previous one also under xlibre):
xrandr-xlibre-new

However, the 'Refresh rate' issue is still there, as well as the sluggish effects, but at least the changes I made today seem to be having an effect. As for the logs, here they are (both after after a reboot, the Xorg one made ofc before all this tinkering):

Xorg.0.log
Xlibre.0.log

And just for completeness sake, output of both inxi and dmesg, respectively:
inxi-xlibre-new
dmesg-xlibre-new

Re: Xlibre release 25.0.0.0 now available for testing

Reply #78
Pls create an upstream issue.

artist

Re: Xlibre release 25.0.0.0 now available for testing

Reply #79
Me again. I did everything what Shoun said, here's the results.
[...]
Well, here are the only notable changes across the provided xorg log (I'll ignore all ABI errors on Xorg side [which are curious, but irrevelant, it's probably due to installed packages left out from Xlibre...]):
Code: [Select]
Xlibre:
[2025-07-10 12:56:22] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) ### Irrevelant
[2025-07-10 12:56:23] (WW) modeset(0): Option "HotplugDriver" is not used ### That's Curious
[2025-07-10 12:56:23] (II) modeset(0): Atomic modesetting disabled ### Irrelevant, modesetting is still disabled anyway
Xorg vs Xlibre:
after this line:
(II) Initializing extension GLX
there's this:
Xorg  : [    20.962] (II) AIGLX: Loaded and initialized radeonsi
Xorg  : [    20.962] (II) GLX: Initialized DRI2 GL provider for screen 0
vs
Xlibre: [2025-07-10 12:56:23] (II) GLX: Initialized glamor GL provider for screen 0
Xlibre: [2025-07-10 12:56:23] (II) GLX: Another vendor is already registered for screen 0

Could you try the last thing:
Put the entire content of this into /etc/X11/xorg.conf as a last resort test:
Code: [Select]
Section "ServerFlags"
        Option "IgnoreABI" "true"
EndSection
Section "OutputClass"
    Identifier "AMD"
    MatchDriver "amdgpu"
    Driver "amdgpu"
    HotplugDriver "amdgpu"
    Option "Accel" "on"
    Option "TearFree" "off"
    # DRI = 3 is the default for Xlibre, while it seems like DRI2 is enabled and working on your vanilla Xorg side which is weird, because it should be 3 anyway... We should at least try...
    Option "DRI" "2"
EndSection
I'd also try comparing loaded modules with modprobe on both Xorg vs Xlibre side. Still, you should do as Artist says since this seems like a non-trivial regression. Make sure to provide all this documentation there.

Re: Xlibre release 25.0.0.0 now available for testing

Reply #80
Well, for some reason using that as my xorg.conf makes lightdm unable to start (which didn't happen before under xlibre). Here's a photo, I tried changing DRI to 3 but same result.


I'd also try comparing loaded modules with modprobe on both Xorg vs Xlibre side. Still, you should do as Artist says since this seems like a non-trivial regression. Make sure to provide all this documentation there.

I think you're referring to the lsmod command? if so, here's the output for both xorg and xlibre. Keep in mind that for xorg, I used the command while on my usual Cinnamon session, but for xlibre (since I was unable to login) it was made while in the tty (as you can see in my photo). Also, the output for dmesg, not sure if it's still useful but there you go.

I think I'll stay on xorg for now, but I'll keep an eye on xlibre ofc. As for Artist's suggestion, I'd like to do it but I've never reported an issue on github before, so excuse me for the dumb question but could you tell me the proper way to do it?  :'(

Re: Xlibre release 25.0.0.0 now available for testing

Reply #81
Just a thought from days gone by as the following has gotten me out of a few binds.

Have you considered running sudo X -configure?

Of course, you will need to kill off you x server and lightdm beforehand and most importantly, make a backup of your current xorg.conf
YMMV of course.

Supercalifragilisticexpialidocious

Re: Xlibre release 25.0.0.0 now available for testing

Reply #82
As for Artist's suggestion, I'd like to do it but I've never reported an issue on github before, so excuse me for the dumb question but could you tell me the proper way to do it?  :'(

But before doing that you'd need to compile the master branch to see if current fresh iterative dev-version (I'd also try switching your current kernel from the vanilla -artix to something like linux-zen (pacman -S galaxy/linux-zen) or linux-lts (pacman -S system/linux-lts) just to test if there are no incompatibilities from this side...)

As for writing the issue, look and search through them to see if there's already something about your hardware (mainly amd vega apu related stuff) or software (cinnamon/gtk/{radeon}dri/modesetting related stuff) config or problems. If there's nothing of substance, simply go and write new issue:
https://github.com/X11Libre/xserver/issues >> new issue >> follow the template.
There's nothing scary about this.


EDIT:
easiest way to do that would be through AUR It seems like that dumb AUR packager made systemd as mandatory dependency, so just disregard anything I said about going through AUR...

Re: Xlibre release 25.0.0.0 now available for testing

Reply #83
EDIT:
easiest way to do that would be through AUR It seems like that dumb AUR packager made systemd as mandatory dependency, so just disregard anything I said about going through AUR...

You may edit PKGBUILD and remove systemd stuff...

Re: Xlibre release 25.0.0.0 now available for testing

Reply #84
[...]
You may edit PKGBUILD and remove systemd stuff...
Yes, this is what I actually done, but I wanted to avoid this since it is still unecessary tinkering in my book, I just took Artist's BUILDPKG for metapackage from https://gitea.artixlinux.org/packages/xlibre-xserver and pointed it to master branch for compilation.

Re: Xlibre release 25.0.0.0 now available for testing

Reply #85
For me everything works (and was i amazed at it) apart from Xft.dpi. There are some issues open on github about dpi stuff but they rather focus on full support for fractional scaling instead of this simple thing which does the job :D
I didn't have any issue with amdgpu drivers either.
If they fix it a bit more i'll give up wayland, because the picom compositor is still better than all of them really.

Re: Xlibre release 25.0.0.0 now available for testing

Reply #86
EDIT:

I encountered an issue of a disappearing mouse cursor using Xlibre. Per recommendation - created a dedicated topic:
https://forum.artixlinux.org/index.php/topic,8425.0.html

Re: Xlibre release 25.0.0.0 now available for testing

Reply #87
It would serve you well to put this in a new subject

 

Re: Xlibre release 25.0.0.0 now available for testing

Reply #88
It seems the issue from https://github.com/X11Libre/xserver/issues/326 - adding your info should help analyze the problem.

artist

Actually that issue is closed since master was found without the issue.  I also tried master (I use the AUR git packages tweaked to remove systemd/logind stuff from it), and it worked fine.

Edit:

Then I decided to try current 25.0.0.5-1 version from the repos, and it seemed dpms worked fine as well, but Today pretty early after boot and starting X leaving it untouched for a while, there was no way to bring the display back, had to kill X from console.  It seems whatever worked out on master hadn't been released yet.

Just to close  on my prior comment about dpms...