grufwub has quit [Remote host closed the connection]
grufwub has joined #wayback
_whitelogger has joined #wayback
mojo_x has joined #wayback
PaulFertser has joined #wayback
<PaulFertser>
Hi folks. I'm giving wayback a spin on Debian 13 (released yesterday). My normal setup is XMonad with a custom Xkb config which I apply with "xkbcomp" from ~/.xinitrc. With wayback it has no effect from .xinitrc (the rest of the file runs) and it has partial effect (which is surprising since it's the same Xkb infra used by Xorg and Wayland) as it switches variant of the primary layout but doesn't
<PaulFertser>
add the second group and my modifier keys changes. xkbcomp output is identical. Is this usecase within the scope of the project?
<PaulFertser>
(btw, if anyone likes fixing documentation there's a chance to improve the wayback-session man page -- it lacks description of the options the app expects)
<PaulFertser>
As a sidenote what I'd be missing in Wayland compared to Xorg are the additional configuration settings the old "synaptic" touchpad driver has to offer, specifically configurable edge scrolling, circular scrolling, mapping of multi-touch events to mouse buttons compared to libinput :/
<dramforever[m]1>
<PaulFertser> Hi folks. I'm giving wayback a spin on Debian 13 (released yesterday). My normal setup is XMonad with a custom Xkb config which I apply with "xkbcomp" from ~/.xinitrc. With wayback it has no effect from .xinitrc (the rest of the file runs) and it has partial effect (which is surprising since it's...
<dramforever[m]1>
it is known that x keyboard settings is incompletely implemented. this is in scope but not currently being worked on afaict
<dramforever[m]1>
<PaulFertser> As a sidenote what I'd be missing in Wayland compared to Xorg are the additional configuration settings the old "synaptic" touchpad driver has to offer, specifically configurable edge scrolling, circular scrolling, mapping of multi-touch events to mouse buttons compared to libinput :/
<dramforever[m]1>
xf86-input-synaptics will not work with wayback. implementing these features is in the scope of libinput. making these features configurable is in the scope of wayback
<dramforever[m]1>
<PaulFertser> (btw, if anyone likes fixing documentation there's a chance to improve the wayback-session man page -- it lacks description of the options the app expects)
<dramforever[m]1>
can you elaborate on what more to document about wayback-session? does not take any other arguments than the session commanf
<dramforever[m]1>
*command
<f_>
The new opts I added
<f_>
I need to document them properly
<f_>
I need to revamp docs entirely actually
<dramforever[m]1>
ah
<dramforever[m]1>
i missed that completely
<f_>
I will work on that later today
<f_>
PaulFertser: yes, input handling is not fully done yet, there's an open issue about that
<PaulFertser>
dramforever[m]1: I'm a bit confused about the keyboard settings as I thought wayland client are using exactly the same libxkblibrary to handle input. I'm aware that xf86-input-synaptics isn't part of libinput, hence I mentioned I'd be missing its features.
<PaulFertser>
dramforever[m]1: when you say "making these features configurable" do you mean a mechanism that would allow "xinput" to talk to real libinput rather than what's inside Xwayland?
<f_>
Plumbing.
<PaulFertser>
That ticket lacks any technical details of what would need to be implemented, even a general outline.
<PaulFertser>
Is there a better way probably, what is the standard Wayland way to configure Xkb, can some utility just talk to the compositor directly probably instead of trying to get the plumbing working through Xwayland or something?
<PaulFertser>
dramforever[m]1: btw, regarding "circular scrolling" feature IIRC it was specifically not added (or even removed!) from libinput based on the claim that "round touchpads" are no longer used. But I'm comfortable having circular scrolling on a rectangular touchpad too...
<PaulFertser>
f_: btw, both startx and xinit accept command to run without an additional option, so probably you can consider not requiring -sesscmd for that so that more people would feel at home.
<dramforever[m]1>
for keyboard i think the problem is we need to implement the mappings inside wayback? i'm not familiar with this
<PaulFertser>
I thought with Wayland configuring keyboard was as easy as with Xorg since they share Xkb...
<PaulFertser>
So not much to map.
<dramforever[m]1>
libinput not supporting circular scrolling is unfortunate, and i don't know what we need to do
<dramforever[m]1>
i think in general emulating xf86-* is out of scope?
<PaulFertser>
dramforever[m]1: :D
<bigmac>
"is out of scope" axtlos had answers for similar questions in the past regarding implementations that break compatibility
<axtlos>
Hm what's up?
<axtlos>
I'm not sure how emulating xf86-* would even work tbh
<PaulFertser>
It's kind of odd how apparently every compositor has to implement custom machinery to handle stuff which was possible in generic manner with e.g. xrandr and xinput on Xorg.
<axtlos>
Generally I don't think we need to emulate it to allow for better input handling, simply adding plumbing so that Xwayland has the input devices directly instead of only having one fake keyboard and pointer device should be enough
<PaulFertser>
axtlos: guess that was a joke, no?
<axtlos>
What was a joke?
<PaulFertser>
axtlos: I was talking about how libinput is limiting my configuration options on purpose and that I'd miss synaptic driver if I switched to Wayland. Then dramforever[m]1 mentioned an idea of emulating it somehow.
<axtlos>
Oh I see
<dramforever[m]1>
"emulating xf86-*" drivers was not a joke, it's just something that won't happen
<PaulFertser>
That means even with the plumbing in place I wouldn't be happy because I wouldn't be able to reproduce the configuration with libinput as it lacks the features.
<axtlos>
Yeah that would probably have to be done in a different project
<PaulFertser>
So can I somehow just pass full xkb config to wayback directly, even if only on startup?
<axtlos>
No wayback doesn't implement any input configs
<axtlos>
The aim is to have all input configuration be handled by X tools, the same way it's done currently
<PaulFertser>
And there's no Wayland-generic way for that kind of thing?
<axtlos>
No
<axtlos>
I believe there is a Wayland protocol that allows for some basic input configuration but we don't implement that
<axtlos>
Nevermind there doesn't seem to be
<PaulFertser>
Hm, but I can change system Xkb files on my own machine prior to starting wayback and then it'll just work?
<axtlos>
I'm not sure if that's how it works
<axtlos>
I suppose you could try
<f_>
PaulFertser: We do not require -sesscmd
<f_>
ah you mean `wayback-session sesscmd-here?`
<f_>
wayback-session will eventually be removed in favour of stock startx/xinit
<PaulFertser>
f_: yes, you do when the user wants a custom path there
<axtlos>
Custom path where?
<f_>
sure
<axtlos>
If the user wants to run something not in the xinitrc they just do wayback-session <cmd>
<PaulFertser>
axtlos: when starting wayback-session if one wants something other than ~/.xinitrc
<axtlos>
Yeah
<PaulFertser>
And current code requires an option for that.
<dramforever[m]1>
axtlos: apparently f_ just changed that to `wayback-session -sesscmd <cmd>`
<dramforever[m]1>
last week
<axtlos>
Uhm
<axtlos>
Why?
<PaulFertser>
Other options were added
<f_>
to add other options
<f_>
maybe I should make optparser support just `w-s <cmd>`
<axtlos>
Yeah that's what I was gonna suggest
<f_>
but then again w-s is a short-term solution
<axtlos>
Yes which is why I'm not even sure if adding options was the right call
<axtlos>
Also the help is wrong in wayback session
<PaulFertser>
axtlos: it often feels as if the people behind Wayland are completely out of touch with the needs and expectations typical *nix hackers have from a GUI system.
<axtlos>
Uhm
<axtlos>
Okay?
<f_>
yes
<PaulFertser>
You confirm the notion?
<f_>
the docs will be fixed
<f_>
PaulFertser: no
<f_>
I was replying to axtlos.
<axtlos>
I mean in the end wayback session is just a short term solution like you said so who cares about the options
<axtlos>
Id just correct the help since it doesn't accept a custom display name
<f_>
what? w-s?
<axtlos>
Yeah
Izzy has quit [Ping timeout: 276 seconds]
<f_>
I was gonna make it accept display ..... but meh
<axtlos>
I mean, works too
<axtlos>
Is it worth the effort tho :p
<bigmac>
is the plan to not have any wayback specific flags at all while launching it?
<axtlos>
The plan is to not have wayback session at all
<PaulFertser>
https://termbin.com/2jeu this borrowed from simple.c wlroots seems to help a lot with configuring xkb on startup to one's liking.
<bigmac>
axtlos: what I meant was,.. would this disallow for optional compositor logic decided before launch rather than at compile time? Say the compositor output scaling would be optional, won't this make it impossible to make it so? The question is if we want to allow anything extra to be passed in
<f_>
I think also we can start deprecating wayback-session altogether
<f_>
given xinit works just fine
<bigmac>
axtlos: thought compositor scaling of output can be an optional feature wayback could have https://termbin.com/im8w
<axtlos>
f_: I can't sign into gitlab rn but the -help output in w-s also references a display option
<axtlos>
bigmac: the question is how does Xorg do it
<f_>
oops
<axtlos>
Xorg does scaling through the dpi flag, so that's how we should do it too
<f_>
copy-paste err
<f_>
axtlos: but -dpi seems not working very well
<f_>
I think having -wayland-dpi would be good
<axtlos>
Is that the case on Xorg itself too?
<f_>
yes
<f_>
not many apps honour -dpi
<axtlos>
In my opinion we should just have flat out xorg compatibility even if that doesn't work properly
<axtlos>
And then once we get the first stable releases we can think about custom features
<f_>
yeah, adding a -wayland-dpi option doesn't work against xorg compat IMO
<axtlos>
It doesn't directly but it still adds extra complexity
<f_>
it doesn't seem to add too much complexity in my POV
<axtlos>
I mean xorg also does scaling through xrandr
<f_>
but I get what you're saying
<f_>
oh, yes it does.
* f_
afk
<axtlos>
Which in the end is the same as having the scaling be done in wayback compositor, just that xrandr is the Xorg solution
<PaulFertser>
Hey f_ , it looks like I can just set XKB_DEFAULT_LAYOUT/VARIANT etc and that works nicely to set initial configuration even without the future planned plumbing.
<axtlos>
Why not just use setxkbmap
<axtlos>
That's what I do
<PaulFertser>
f_: "*Xwayback* :_display_ _args_" <-- I would read it as if both :display and args are mandatory options.
<bigmac>
axtlos: are you able to change the scale with --scale ? something like.. xrandr --output XWAYLAND0 --scale 2x2 within of wayback
<PaulFertser>
axtlos: on X11 I personally have to use xkbcomp to have few additional snippets of configuration which are not present in Xkb upstream (specifically, I need left and right Alt keys to map to different modifiers and also I swap left shift and left capslock).
<axtlos>
I see so setxkbmap doesn't work?
<axtlos>
bigmac: as in I should try right now?
<PaulFertser>
axtlos: also #46 says setxkbmap currently doesn't work for all the features somehow.
<PaulFertser>
And by setting those env variables one would configure the compositor rather than Xwayland layer so that should be better either way I guess?
<axtlos>
Yeah depending on the needs it would be better
<PaulFertser>
And it works already without any code changes, just nobody told me I should try :)
<bigmac>
axtlos: If you are in wayback anyways, just changing the scale and seeing if it actually does anything inside of xwayland would be helpful to me, because it does nothing on my end I have no other device than my macbook pro atm. Anyhow, about what you wrote about first getting a stable release and then thinking about similar features, should I comment on #11 linking with the WIP work I sent here
<axtlos>
Xrandr scaling doesn't seem to work for me
<axtlos>
Instead of working on a workaround in the compositor end we should figure out why it doesn't work and fix that
<axtlos>
The compositor shouldn't be handling scaling if it's doable in Xorg
<PaulFertser>
Shouldn't the apps themselves just render whatever they want rendered doing scaling as they see fit? They know the real DPI, the font rendering libraries can do whatever size in "pt" they are asked to show and it'd automatically the right size (pt == 1/72") on any screen with any pixel density?
<bigmac>
What eleven is mentioning is applying scaling automatically, given the most common DPI among the outputs. PaulFertser: well they do not know the real DPI ..afaik.., the default is 96 and one can overwrite it with the -dpi flag, but this does not work very reliably. You can try it out for yourself, but on icewm half of the ui is scaled and half is not
<PaulFertser>
bigmac: I know the situtation with dpi is silly in Xorg land but I feel like all that is because people keep insisting on "give me scaling" instead of investing into fixing apps/GUI frameworks they care about.
<bigmac>
PaulFertser: scaling is not ideal as everything is blurry, but at least it is usable. I mentioned this to be an optional feature. The scale factor should be at around 2.6 on my retina display (250/96) (dpi of the retina display / default xorg dpi). It is a bit blurry, but still better than passing -dpi 250 and having the system be unusable due to things overlapping and better than having the dpi
<bigmac>
be 96 and not being able to read what's written anywhere at all
<bigmac>
However I agree that getting xrandr to work would be better than scaling it from the compositor for our purposes
pinskia has quit [Read error: Connection reset by peer]
pinskia has joined #wayback
<bigmac>
Though I am unsure if we can make it apply automatically that way
lanodan has quit [Ping timeout: 245 seconds]
lanodan has joined #wayback
<f_>
axtlos: btw, when do you think is appropriate for us to kill wayback-session?
<f_>
startx/xinit works perfectly fine, `startx -- /usr/bin/Xwayback` work
<axtlos>
When it's possible to have /usr/bin/X point to Xwayback and startx to work like that