The Linux Thread - The Autist's OS of Choice

  • 🐕 I am attempting to get the site runnning as fast as possible. If you are experiencing slow page load times, please report it.
Betonhaus said:
HDR support doesn't sound too hard to pull off, but how is the multi monitor thing hacky? And how hard would it be to fix,
Click to expand...
Multimonitor support on X11 is usually done by tricking X11 into thinking your monitors are one big screen. Thats why compositors cant handle multiple monitors with different refresh rates and fractional scaling doesn't work. X11 does have multihead support, but that comes with the catch of it essentially being two seperate instances of X11 and applications cant move between them, only the mouse.

There was asyncflipsecondaries that made it so that instead of compositors using the lowest refresh rate it used the highest, fixing the issue of seperate refresh rates, but that comes with the issue of tearing if the monitors are not similar (120hertz & 60hertz = 60hertz tearfree, 144hertz & 60hertz = tearing on 60hertz).

It would require changing the way X11 views monitors, so ig pretty hard.
 
  • Informative
  • Agree
Reactions: Wol, HalHalliday, YoRHa No. 2 Type B and 2 others
Rust Troony said:
It would require changing the way X11 views monitors, so ig pretty hard.
Click to expand...
I suspect it's not as hard as people want to believe. The problem is that the freedesktop people have been gatekeeping any improvements to XOrg for more than a decade at this point, in order to "encourage" development of wayland, so nobody has actually had the opportunity to make the changes.
 
  • Agree
  • Thunk-Provoking
  • Like
Reactions: Grin Machine, Blackhole, Vecr and 10 others
teriyakiburns said:
I suspect it's not as hard as people want to believe. The problem is that the freedesktop people have been gatekeeping any improvements to XOrg for more than a decade at this point, in order to "encourage" development of wayland, so nobody has actually had the opportunity to make the changes.
Click to expand...
I would like to know the theory behind the change though, as it sounds like the framerate gets set before the buffer is split off into different screens.

Maybe you could have something like each display is it's own x11 instance but have applications belong to one instance but the part that's on the second screen be "mirrored" to it with a sort of screen capture system that will pass mouse clicks back to the main app in its original x11 instance, then jump to the other. That would mean that the app could have v-sync issues on the second screen when it's overlapping but it wouldn't be as severe.
 
  • Thunk-Provoking
Reactions: teriyakiburns
teriyakiburns said:
I suspect it's not as hard as people want to believe. The problem is that the freedesktop people have been gatekeeping any improvements to XOrg for more than a decade at this point, in order to "encourage" development of wayland, so nobody has actually had the opportunity to make the changes.
Click to expand...
Might be optimistic, but I am inclined to believe that XLibre will fix a lot of the persistent artificial issues X11 has been dealing with for years in a fraction of that time, especially if developers from Artix and other anti-RHEL communities contribute.
 
  • Agree
  • Like
  • Winner
Reactions: Grin Machine, YoRHa No. 2 Type B, Jang Joo and 6 others
Betonhaus said:
Maybe you could have something like each display is it's own x11 instance but have applications belong to one instance but the part that's on the second screen be "mirrored" to it with a sort of screen capture system that will pass mouse clicks back to the main app in its original x11 instance, then jump to the other.
Click to expand...
This is kind of similar to one of the solutions previously employed, before the whole "merge the monitors" thing, and very similar to the solution Apple uses in MacOS (IIRC, anyway). Having windows cross display servers is a very complicated problem to solve, though probably not insurmountable.
 
Ferryman said:
Might be optimistic, but I am inclined to believe that XLibre will fix a lot of the persistent artificial issues X11 has been dealing with for years in a fraction of that time, especially if developers from Artix and other anti-RHEL communities contribute.
Click to expand...
teriyakiburns said:
I suspect it's not as hard as people want to believe. The problem is that the freedesktop people have been gatekeeping any improvements to XOrg for more than a decade at this point, in order to "encourage" development of wayland, so nobody has actually had the opportunity to make the changes.
Click to expand...
I think it will be a slow burn, it is only like 4 developers from what i can see. We will get a huge bugfix that will make Xlibre worth it to change to but it will fizzle out into a slow burn of updates. It would probably take at least a year or two before these issues would be solved, if ever.

Rust Troony said:
There was asyncflipsecondaries that made it so that instead of compositors using the lowest refresh rate it used the highest
Click to expand...
I decided to try this out as i hadn't ever actually touched it. Using xfces' built in compositor gave visual glitches and turning the compositor on and off too fast ended up hard crashing the system lmao. Switched over to picom and it was solved, however even using the "similar refresh rate" my secondary monitor still has screen tearing, and didnt really change much worst when i went to my main monitors highest refresh rate (144hz), main monitor is still buttery smooth without screen tearing, so im staying with it. Good to see it actually works though, this was one of the pain points making me want to switch back to Wayland, now i guess im here permanately.
 
  • Feels
Reactions: Verpa Teutonica Ingens
Rust Troony said:
The only actual usecase for normal users of wayland is non-hacky multimonitor support and now also HDR. Outside of that wayland has no advantage, only disadvantages.
Click to expand...
I use it because I like 1:1 gestures on my laptop and I can't find a way to have them in xorg (except in a GNOME extention but GNOME is leaving xorg soon)
 
  • Agree
Reactions: YoRHa No. 2 Type B
teriyakiburns said:
This is kind of similar to one of the solutions previously employed, before the whole "merge the monitors" thing, and very similar to the solution Apple uses in MacOS (IIRC, anyway). Having windows cross display servers is a very complicated problem to solve, though probably not insurmountable.
Click to expand...
Can an application be transferred to a different display server seamlessly without visible glitching?

What would be the overhead if you had split the display server into two parts where each window gets its own for one part and each display gets its own for the other part?
 
Rust Troony said:
I think it will be a slow burn, it is only like 4 developers from what i can see. We will get a huge bugfix that will make Xlibre worth it to change to but it will fizzle out into a slow burn of updates. It would probably take at least a year or two before these issues would be solved, if ever.
Click to expand...
Considering the sheer volume of (attempted) contributions Enrico added to X11, the burn might be slow, but it will certainly be better than the ditch it now lies in. Even incremental improvement is still categorically better than what amounts to total stagnation.
 
  • Agree
Reactions: HalHalliday, Vesperus and Rust Troony
Last edited:
  • Winner
  • Like
  • Agree
Reactions: Vecr, Vesperus, Sake Ojone and 1 other person
analrapist said:
OpenMandriva has landed an xlibre package, apparently? Any OpenMandriva stans in here?
Click to expand...
I really like OpenMandriva and use it on a few machines (still committed to Gentoo for my main machine), but its only in the Cooker branch for now which is for developers.
Once it hits the Rome branch (the normal rolling branch) I will give it a try. I imagine it will be the same as Xorg for the time being, maybe with some bug fixes.
Not surprised they got a package out for XLibre already, I wonder if they will switch out Xorg soon?
 
Ferryman said:
Would it be more viable to try and run Gentoo with extremely restrictive USE flags that completely disable anything and everything systemd? OpenRC fetches like half the systemd tree for dependency resolution straight up, but perhaps through restricting it significantly, you can straight up prevent it from pulling them back in once purged? Or just do

``` USE ="-systemd -dbus -elogind -tmpfiles -ukify -systemd-boot -sysusers" emerge world ```
Click to expand...
Yes, you can do that fine, just make sure you avoid selecting the desktop profile in eselect to avoid the most normiefied setup. You could use "default/linux/amd64/23.0/split-usr/no-multilib/hardened" if you know what you're doing for example.

If you want to check out why openrc is pulling the stuff it does, you can check the openrc ebuild itself:
Bash: 
~ # equery w openrc
/var/db/repos/gentoo/sys-apps/openrc/openrc-0.62.3.ebuild
Bash: 
COMMON_DEPEND="
        sys-libs/libcap
        sys-process/psmisc
        pam? ( sys-libs/pam )
        audit? ( sys-process/audit )
        selinux? (
                sys-apps/policycoreutils
                >=sys-libs/libselinux-2.6
        )"
DEPEND="${COMMON_DEPEND}
        virtual/os-headers"
RDEPEND="${COMMON_DEPEND}
        bash? ( app-shells/bash )
        sysv-utils? (
                !sys-apps/systemd[sysv-utils(-)]
                !sys-apps/sysvinit
        )
        !sysv-utils? (
                sysvinit? ( >=sys-apps/sysvinit-2.86-r6[selinux?] )
                s6? ( sys-apps/s6-linux-init[sysv-utils(-)] )
        )
        virtual/tmpfiles
        selinux? (
                >=sec-policy/selinux-base-policy-2.20170204-r4
                >=sec-policy/selinux-openrc-2.20170204-r4
        )
"
The only thing I see that forces systemd shit is
Code: 
virtual/tmpfiles
Bash: 
 ~ # equery g virtual/tmpfiles
 * Searching for tmpfiles in virtual ...

 * dependency graph for virtual/tmpfiles-0-r5
 `--  virtual/tmpfiles-0-r5  amd64 
   `--  sys-apps/systemd-9999  (sys-apps/systemd) M[package.mask] 
   `--  sys-apps/systemd-utils-255.18  (sys-apps/systemd-utils) amd64  [tmpfiles]
[ virtual/tmpfiles-0-r5 stats: packages (3), max depth (1) ]
You can bypass that if you really don't care about tmpfilesd by adding a line to /etc/portage/profile/package.provided/* to tell gentoo that "yes yes, I handled it and I know what I'm doing, now go away":
Code: 
# /etc/portage/profile/package.provided/gentoo
virtual/tmpfiles-9999
 
  • Informative
  • Winner
Reactions: Smith Banquod, GoysGoneWild, Trans Fat 41g and 1 other person
Another Char Clone said:
sic
Click to expand...
Interesting. I was pretty dead set on ditching the 'too but you are making me reconsider. Might even be possible to rip Obarun's 66/s6 service system style to handle what tmpfiles does. The Obarun head (only?) dev does seem genuinely dedicated to rebuking systemd, but one man shows are always kinda iffy. Then again Artix's dev team is also pretty small, but the bus factor argument remains.

Can you think of any tmpfiles alternatives? Short of writing a bespoke script I can't really see anything that measures up. Maybe Antix's way of handling it through a very basic cron job for cleanup a la

find /tmp -type f -mtime +1 -delete
 
Would Linux Mint Ubuntu Edition not have Xlibre when LMDE gets it, if the project gets that far?
 
Another Char Clone said:
You could use "default/linux/amd64/23.0/split-usr/no-multilib/hardened
Click to expand...
no-multilib 4 lyfe

Betonhaus said:
Would Linux Mint Ubuntu Edition not have Xlibre when LMDE gets it, if the project gets that far?
Click to expand...
I don't really know about mint specifically but I feel like they aren't particularly known for being fast to adopt anything. A lot like debian. But who knows.
 
You must log in or register to reply here.
Back