<f_>
> However, challenges remain. Feedback from the Phoronix Forums on the 0.1 version indicated issues with hardware acceleration, and while 0.2 makes strides in GPU passthrough, it’s still alpha-level software. Experts caution that widespread adoption hinges on resolving these, especially for performance-critical applications.
<f_>
when did I ever mention GPU passthrough :>
mojo_x has quit [Ping timeout: 276 seconds]
<f_>
It feels AI-generated
HadiChokr[m]1 has joined #wayback
<HadiChokr[m]1>
It defenitly is.
<HadiChokr[m]1>
> Used in niche Linux Distributions
<HadiChokr[m]1>
Fedora and Alpine are niche? With more to follow? Whut.
<f_>
hehe
<f_>
better laugh than cry
<f_>
lol even the banner image is ai-generated
<f_>
> With version 0.2, developers have focused on stability improvements, including better handling of window management and input events, which were rudimentary in the 0.1 release.
<f_>
I also never mentioned window or input management, so I have no idea where they got that idea from either
<f_>
> but 0.2 reportedly resolves several of these, adding preliminary multi-monitor capabilities and refined clipboard synchronization
<f_>
if only
<f_>
anyway I won't spam this channel with AI slop any further, but I just find this coverage really funny.
caskd has quit [Ping timeout: 248 seconds]
<anabelae[m]>
That article is mental. The apparent laxness in verifying information is astounding. Not everyone can be Hiya
<hiya>
anabelae[m]: What? What did I do?
<hiya>
:)
<f_>
hiya: not just spew out AI slop about Wayback I suppose :P
<anabelae[m]>
hiya: You made an article mentioning wayback that was well researched, evident by you being in this room. What I am discussing is the AI generated article a few messages up
caskd has joined #wayback
<hiya>
anabelae[m]: f_ Thank you for the kind words. My bulletin, issue 1 is coming tomorrow. I have some good news headlines lined up
<hiya>
way way back is of course included.
<f_|cat>
you are welcome
<hiya>
Also, thank you for the kind contributions.
<hiya>
I wanted to put the real gift of it out from real users/devs.
<hiya>
gist*
<panekj>
f_: unfortunately "news" are mostly about pushing articles faster and quicker than everyone even if it's fake news/slop
<bigmac>
f_: "I just tested with IceWM and yep it seems some don't follow -dpi" So with this, do you think it's worth it to at least have a wayback-session flag with which the most common dpi would be found and set?
<f_>
bigmac: hmm in my testing it does seem to follow -dpi in some places, namely the taskbar
<f_>
but things like librewolf don't
<bigmac>
in icewm specifically the task bar on the bottom gets it completely wrong
<f_>
hmm it gets right for me
<bigmac>
the time respects it, but the container surrounding it does not
<f_>
for me all the taskbar respects it
<f_>
theme 'yamm' fwiw
<bigmac>
Try helix. NanoBlue looks the most OK, because it seems to ignore the dpi completely. I do not have any themes starting with "y" installed, is it a default theme?
<f_>
I think it's in some debian themepack or something
<f_>
I got it from some random github repo
<bigmac>
Out of all the terminals I've tried just alacritty respects it nicely. But then it's again broken, because the title bar does not expand in accordance to the bigger text. If such flag, for adjusting the dpi, gets implemented and it will leave people's desktops is all kind of shapes, will it get blamed on wayback? I don't think people are used to adjusting the dpi itself, usually there's like a
<bigmac>
scale which applies to everything, for example in GNOME I believe?
<f_>
hmmm
<bigmac>
I think it's either not doing anything and closing #11, or implementing a flag which puts the responsibility of the desktop looking alright over to X (passing -dpi flag over to it), or implementing a flag which scales the Xwayland client as a whole leaving the responsibility over at wayback (however breaking the mentioned compatibility, because from within Xwayland it looks like the dpi is still
<bigmac>
the default 96, but the resolution is not native)
<f_>
hmm maybe there's a compromise between the two
<f_>
I would be in favour of implementing a new -wayland-dpi flag .. so people who are fine with Xwayland -dpi can use it, and the remaining can use -wayland-dpi
<f_>
What do you think?
<f_>
That being said, optparse has a bug that makes options with operands not get parsed correctly
<bigmac>
f_: So to implement flags for both output scaling with the compositor handling it and Xwayland -dpi ? Yeah I can try doing it, we can then test it and see if we want to keep it :)
__0x1eaf has joined #wayback
ConanKudo[m]1 has quit [Quit: Idle timeout reached: 172800s]
<f_>
Oh you can just disregard -dpi
<f_>
In Xwayback any non-handled args are passed over to Xwayland
<f_>
bigmac: thank you for looking into that, by the way :)
<f_>
I really appreciate it and I'm sure I'm not alone in that thought
<f_>
axtlos, navi: btw, regarding tty changing, From what I can tell Xorg has a suid wrapper for permissions and such
<navi>
Xorg itself
<navi>
used to be shipped as suid
<navi>
distros don't do this anymore bc [e]logind integration and well suid is dangerous
<f_>
yep
<navi>
gentoo still has that option if USE="-systemd -elogind suid"
ConanKudo[m]1 has joined #wayback
<ConanKudo[m]1>
and that's not really a feature worth reimplementing
<navi>
i think tty changing is, but shipping suid is not
<navi>
because there's other ways to allow tty changing
<navi>
(user in tty group, or agetty login)
<f_>
I think the only feasible ways to allow tty changing is to either add (optional) logind integration .. or teach users to just do the switching themselves, or what navi mentioned
<navi>
though for agetty login is less "tty changing" and more "use the current tty please", i used to pass vt1 to xorg just so i could avoid elogind
<f_>
logind's great :p
<navi>
not really but that's unrelated
<navi>
wlroots only really supports seatd on that end anyway
<navi>
so imo the best we can do is handle `vtX` as just "try to switch and warn if it fails"
<f_>
why? It's greaaaaaaaat :p
<navi>
and be done with it
<f_>
(/j)
<navi>
i need to work on sessiond, and figure out what to do with power management
<navi>
then we'll have logind but with a sane separation
<f_>
openrc-sessiond you mean?
<f_>
like, some logind reimplementation is what you mean, right?
<navi>
not openrc-specific because, why would it be
<navi>
it's the session management part of logind
<f_>
no of course not
<navi>
i'm not naming anything `openrc-*` if it's not part of init / service management because people always confuse things
<f_>
Makes sense.
<navi>
sessiond or whatever-it's-name is an api to register and query sessions, similar to that subsection of logind or utmpx but sane
<navi>
logind does 3 distinct tasks, it's a session database, a seat manager, and a power manager
<f_>
And you want to split these
<f_>
into 3 different tools
<navi>
we already have seatd with libseat as an api
<navi>
so the other two only make sense to have them split as well, because they're not inherently inter-dependent
cow has quit [Read error: Connection reset by peer]
cow has joined #wayback
caskd has quit [Ping timeout: 276 seconds]
caskd has joined #wayback
pinskia has quit [Read error: Connection reset by peer]
pinskia has joined #wayback
cow has quit [Ping timeout: 272 seconds]
cow_ has joined #wayback
mojo_x has joined #wayback
__0x1eaf has quit [Quit: Lost terminal]
mrkomododragon2 has joined #wayback
pinskia has quit [Read error: Connection reset by peer]
pinskia has joined #wayback
<bigmac>
f_: "In Xwayback any non-handled args are passed over to Xwayland" And when starting via the wayback-session command? Is it not the preferred one. It currently crashes if I do "wayback-session i3 -dpi 100". How should it be used currently so the dpi flag gets passed down
vimpostor has quit [Remote host closed the connection]
<f_>
What do you mean by "crashes"?
<f_>
It should just complain about args instead of crashing
vimpostor has joined #wayback
<dramforever[m]1>
that just runs i3 -dpi 100 right
<bigmac>
It believe it is due to it reading "-d" and then assuming what follows is the display f_