00:26 eruditehermit: I just learned that there is a separate DE and display server clipboard. What is the best way to sync them in KDE?
00:31 eruditehermit: nvm I found the setting
00:42 bluetail: I noticed that when I run dotool, I can make it persist even after I closed my window manager. E.g sway. Then I am at sddm and it still runs if it was detached with &
00:43 bluetail: Is that a security issue?
07:26 MrCooper: bluetail: sddm runs as a different user, right? If so, clients from your session shouldn't have access to sddm's Wayland display (if any)
07:35 kennylevinsen: dotool uses uinput, i.e. it uses a kernel interface to create a new virtual, low-level input device. Running such a tool at any point is likely a bit of a security issue (either dotool running as root, or unsafe system privileges to let it run as a user), but it is expected that it will work everywhere as long as it is running
08:25 mehdix: Hi there. I have a strange bug since a year or two and I could pin point it down to Firefox rendering canvas html elements. I lauch two instances of Sway in two different ttys without a display manager. When switing from one to the other, often GPU goes crazy. using amdgpu_top I could find the problem with Firefox. Is this a Firefox bug or a Wayland one?
08:28 mehdix: When switching TTY (Alt+Ctrl+F1-4) Firefox GPU usage goes to close 100% and the computer hangs after a while. Just today I tried rendering pages with canvas (games and alike) and noticed this happens when I'm on such a page and then switch tty. If I close that tab, switching does not cause any issue.
08:30 mehdix: The OS is Arch Linux with AMD CPU and GPU.
08:33 dottedmag: mehdix: It might be anywhere in the stack from FF to kernel. Please do file a bug report in Firefox bugtracker
08:34 soreau: it also could be seatd not telling wlroots to stop rendering, I have a similar issue
08:34 mehdix: dottedmag, I want to gather useful information on the bug before filing it.
08:34 soreau: with wayfire though - if I switch to a tty, wayfire on the other tty takes 100+% cpu
08:36 mehdix: soreau, that's interesting. since sometimes I notice switching back immediately stops the gpu usage back to close to zero
08:36 mehdix: but not always
08:37 soreau: basically these signals aren't ticking like they're supposed to always https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/backend/session/session.c?ref_type=heads#L46
08:37 mehdix: dottedmag, bty, firefox bug tracker is such a graveyard. I have bugs with details hanging there since years...
08:39 soreau: mehdix: afaict, the active bool never becomes false, so if there's nothing to render, it paints as fast as possible, but switching back, it always fixes itself here
08:41 soreau: cc kennylevinsen ^^
08:43 mehdix: very interesing. previously I thought switching to an empty tty and then to Sway might have prevented the issue, but I guess it has nothing to do with it. I can try with wayfire later too.
08:43 soreau: I previously thought that upgrading seatd fixed things but the bug keeps coming back still
08:45 mehdix: It's bothering me for over a year now (probably since I switched to using to sessions).
08:45 soreau: I login with a dm, but test on another tty and the issue is obvious
08:46 mehdix: soreau, have you filed a bug for it? Since you can apparently very accurately reproduce it.
08:46 soreau: it is possible that the issue went away when I was using greetd/gtk-greet instead of lightdm, but I have not investigated enough to know for sure yet
08:46 soreau: mehdix: only mentioned it to kenny :P
08:47 soreau: they put up a logind-debug branch to output more info
08:47 soreau: of seatd
08:47 mehdix: I use no dms and it happens every single day.
08:47 kode54: I log in with a DM too
08:47 soreau: but sadly, I have not used that branch to find out more yet :P
08:47 kode54: but I use uwsm through a custom .desktop file
08:48 kode54: since I use GDM, I also get automatically logged into gnome keyring
08:48 kode54: gnome keyring is my preferred gpg secrets holder, too, because it lets me save the passkey to my keychain
08:49 kode54: I also use libsecret cli tool to store my email passwords for notmuch syncing
08:49 kode54: </offtopic>
08:50 kode54: mehdix: firefox does other stupid crap here with a single labwc instance
08:50 kode54: when I had my mixed 2.0 / 1.0 scale monitors setup
08:50 kode54: the 2.0 monitor has a firmware bug where it disconnects itself momentarily whenever it turns on or wakes from DPMS state
08:51 kode54: this would cause the output to reset, and with labwc, it defaults to the 1.0 scale on that monitor (wlroots overrides don't apply, because the EDID lies about the monitor's dimensions, so it's "less than 192dpi")
08:51 kode54: kanshi then resets the scale to 2.0
08:51 kode54: I reproduced it with booting an instance of labwc, then manually setting the output scale to 2.0
08:52 kode54: firefox will have sizing issues that become apparent when another window overlaps the top left corner of the firefox window
08:52 soreau: mehdix: I guess I thought that I was the only one with the bug, or else I would have heard it reported at least to wayfire, but maybe people don't switch tty's and check the compositor usage regularly
08:52 kode54: or if the top left corner of the window is moved outside the screen
08:53 kode54: the glitch presents as firefox strobing its scale between double scale with a buffer scale of 1.0, and double scale with a buffer scale of 2.0
08:53 kode54: and other parts of the UI glitch out rapidly
08:53 mehdix: kode54, we have a bug here don't we? Where should it be filed? And is this really a Firefox issue or the compositor can prevent that?
08:53 kode54: it ceases if the corner of the window is made visible again
08:53 kode54: I filed my issue with labwc
08:53 dottedmag: TBH Quartz's decision "outputs are separate" sounds more and more sane every time I see problems reported by a window straddling several outputs :-)
08:53 kode54: it probably should be filed with firefox too
08:54 kode54: dottedmag: what do you do when one output momentarily hops the bus?
08:55 mehdix: fwiw, I have had this issue with one or two screens. It makes no difference (your detailed references are great and well beyond my current knowledge about the stack atm)
08:55 kode54: https://github.com/labwc/labwc/issues/2130
08:55 kode54: see that video posted there
08:56 kode54: my current setup has two 1.0 scale screens
08:56 kode54: and both of them remain firmly attached to their ports when power cycled
08:56 kode54: alas, now I have another issue, VRR doesn't work with the HDMI one
08:56 dottedmag: kode54: hmm? I don't know. I guess all the windows displayed there end up somewhere else. However there seems to be some position/size caching in Quartz keyed by output configuration, as whenever I connect an external monitor to a laptop, windows do move to their previous positions.
08:56 kode54: I reported that to the drm/amd tracker
08:56 soreau: mehdix: but if you want to poke around, apply this to seatd, see what it says and maybe file an issue https://git.sr.ht/~kennylevinsen/seatd/commit/6762334fea29214c072a6e91aa0be23250007725
08:57 kode54: I have another nag with quartz and detaching monitors
08:57 kode54: it forgets what refresh rate you set before it detached
08:57 kode54: so my stupid 4k VRR panel can't be kept in VRR mode
08:57 kode54: thanks, Apple
08:57 mehdix: kode54, just tried and on Sway I have not that issue. Window overlapping work flawlessly.
08:58 kode54: mehdix: as I filed it as a labwc issue
08:58 dottedmag: kode54: Amen. I guess you have already tried hammerspooning it?
08:58 kode54: hammerspooning it?
08:59 kode54: I'll look into that next time I find my USB-C to DP cable
08:59 mehdix: soreau, thanks for the link, will definitely do that! I came here to understand which component is causing the issue.
08:59 dottedmag: https://www.hammerspoon.org/ - I use it to do a pseudo-tiling. It definitely knows how to react to output change events. I don't know if it exposes enough API to change refresh rates on the output.
08:59 dottedmag: Sorry, </offtopic>
08:59 mehdix: kode54, would you mind posting the link?
09:00 soreau: mehdix: np, I might try it as well when I have some gumption to do it
09:16 kode54: mehdix: which one?
09:16 kode54: I only reported it for labwc, the issue is the github link above
09:22 mehdix: kode54, sorry was testing seatd and was logged out (can't see older messages even though I have a znc...)
09:23 mehdix: good news is, I enabled seatd service in Arch and so far I have not hit the aforementioned bug
09:44 vnd: Hey guys, hope you can save my arse, so to speak.
09:44 vnd: We have an i.MX6DL embedded board, running community flavor flavor of Yocto BSP (meta-freescale) with weston (8.0.0) and gstreamer 1.16.
09:44 vnd: There's a FullHD display connected, natively in landscape mode, but must be used in portrait mode.
09:44 vnd: So it's rotated in weston.ini (transform=270).
09:44 vnd: Now the problem: higher resolution video (about half of FullHD, occupying half of the screen) is very teared/jerky.
09:44 vnd: FPS by itself is not an issue, reported around 30 by fpsdisplaysink.
09:44 vnd: Now if display rotation is disabled (transform=0), video is smooth.
09:44 vnd: Video is played via gst-launch-1.0 with waylandsink.
09:44 vnd: I've backported "rotate-method" waylandsink support, which effectively calls wl_surface_set_buffer_transform(), among other things.
09:44 vnd: The idea was to match weston rotation and video rotation so that they cancel out.
09:44 vnd: The commit didn't apply cleanly, but I think I've figured it out and ported properly.
09:45 vnd: Video is indeed rotated, but still teared/jerky.
09:45 vnd: Any ideas? Anywhere to look in particular? At this point not even fully sure if it's more about weston, or gstreamer.
09:45 vnd: Any ugly workaround would do, basically I need to make weston not rotate the video, as it will pre-rotated already.
10:32 kennylevinsen: mehdix: I need to put out a bugfix release at some point, the issue is fixed in master
10:33 kennylevinsen: (for libseat)
10:34 bluetail: kennylevinsen about dotool: I am a normal user and it wasnt started with sudo. I use archlinux latest. I haven't added my user to group input as man states. "dotool requires write permission to /dev/uinput, which is
10:34 bluetail: granted to users in group input by a udev rule."
10:34 kennylevinsen: bluetail: your user should never be in group input, that would undermine all input eavesdropping security :/
10:35 bluetail: maybe I should tell gebby, the author of dotool. They explicitly state it.
10:36 kennylevinsen: are you sure your user isn't in the input group? run `groups`
10:36 bluetail: yes
10:36 bluetail: https://0x0.st/X3lk.txt
10:38 bluetail: hmm
10:38 bluetail: theres a 80-dotools.rules file
10:38 bluetail: https://0x0.st/X3ln.rules
10:38 kennylevinsen: yes, but it grants permissions to the input group
10:39 bluetail: I see, but I am not seeing myself in that group at all
10:40 kennylevinsen: you can check what user the service is running as, and use `getfacl /dev/uinput` to see what the active permissions on the file is
10:40 ericonr: Is there a chance the executable is simply suid?
10:40 bluetail: https://0x0.st/X3l5.txt
10:42 kennylevinsen: it has an explicit grant to your user, possibly another udev rule setting a "uaccess" tag. `sudo udevadm info /dev/uinput` should tell you if that's the case, although it won't tell which rule.
10:43 kennylevinsen: maybe you installed something else that also had a uinput udev rule
10:43 bluetail: https://0x0.st/X3l7.txt
10:43 bluetail: I would think only antimicrox would appear to apply for that
10:45 bluetail: https://github.com/AntiMicroX/antimicrox/blob/master/other/60-antimicrox-uinput.rules
10:45 bluetail: Does this do it?
10:47 bluetail: ag input at /usr/lib/udev/rules.d => https://0x0.st/X3lh.txt
10:48 kennylevinsen: yup, then that's why it works for you
10:48 kennylevinsen: uaccess tells logind to give access to any logged in user on top of the normal posix permissions using ACLs
10:49 bluetail: wait but ctrl+f => steam ... ? so steam is the cause for this?
10:50 bluetail: if you know, can you please state which application is the cause
10:50 kennylevinsen: you just sent the link yourself, antimicrox
10:51 kennylevinsen: so this means that while you are logged in, any process can use uinput to create new virtual input devices for typing. Unlike being a member of "input", they do not gain the ability to eavesdrop on your actual input devices.
10:51 kennylevinsen: but there is no revocation, so if you start a service it can run forever even after you log out as permissions only apply at the time of open
10:52 bluetail: I don't quite like that. Should I post a issue on antimicrox?
10:55 kennylevinsen: well, you can't really get more fine-grained permission for uinput without your user itself losing access, so the alternative is *not* using something relying on uinput
10:57 bluetail: I see. Thanks
13:36 soreau: kennylevinsen: I don't think the issue is fixed on seatd/libseat master, because I'm using master and still able to reproduce the issue
14:28 wlb: wayland-protocols Merge request !335 opened by () Draft: Add input-observation protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/335
15:03 DemiMarie: Ping on <https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/409>. If it would help review I can move the test to its own MR.
16:48 wlb: weston Merge request !1617 opened by () DRM: offload blend-to-output color transformation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1617 [color-lcms plugin], [Colour management], [DRM/KMS backend]
17:59 wlb: weston/main: Derek Foreman * desktop-shell: Don't try to move parented views on output removal https://gitlab.freedesktop.org/wayland/weston/commit/067e977fe1ce desktop-shell/shell.c
17:59 wlb: weston Merge request !1616 merged \o/ (desktop-shell: Don't try to move parented views on output removal https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1616)
18:11 colinmarc: wl_seat has this: "This object is published as a global during start up, or when such a device is hot plugged." It seems like most clients don't keep their registry around to get new global events, is that an established pattern?
18:11 colinmarc: context is whether a game controller should be a global or should have a "manager" object: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/244#note_2578217
18:13 soreau: in theory, clients would handle global create/destroy properly, but afaik, most don't
18:15 emersion: colinmarc: i'd assume clients do keep their registry around, to at least get wl_output hotplug events
18:15 emersion: wl_seat hotplug is a bit more rare
18:16 emersion: (wl_output was the only way to get HiDPI working until recently)
18:19 colinmarc: right, that makes sense
18:20 colinmarc: am I right in thinking that global_remove is a bit of a kludge for a gamepad being unplugged, though?
18:21 colinmarc: or is that a good way to do it?
18:23 soreau: there is a wl_seat release event, maybe that's what they should listen for?
18:24 emersion: it depends
18:24 soreau: oh right, that's a request, not event
18:24 emersion: well
18:25 emersion: in general input devices aren't directly exposed as globals
18:25 emersion: they are behind a wl_seat
18:25 emersion: see for instance wl_keyboard, wl_pointer, the tablet protocol
18:26 emersion: https://wayland.app/protocols/tablet-v2#zwp_tablet_seat_v2
18:26 emersion: might not need all of that complexity if you don't need more than one object per seat
18:27 soreau: but for apps, they can usually get joystick events from another means than piping them through the compositor first?
18:28 colinmarc: soreau yes, but that's what the proposed protocol would change
18:31 soreau: well it does sound like a manager for events would be easier to manage than trying to keep up with globals..
18:31 soreau: but I don't really understand the reason for the proposed change
18:32 colinmarc: @emersion thanks, I will mention the tablet protocol in the thread, that seems like a good thing to copy (even if there's not the intermediate object, you could still take a seat as an argument)
18:32 soreau: seems like you'd have extra hops between your input and the game app..
18:32 soreau: and people wouldn't want this
18:32 emersion: soreau: and it's fine for keyboards?
18:33 soreau: emersion: well for keyboards, you need to dispatch the events to 'a client' that has 'keyboard focus', right?
18:33 emersion: why should gamepads be different?
18:33 colinmarc: mice is actually the one where people really care about latency, usually, and that also goes over wayland
18:33 emersion: why shouldn't i be able to navigate around in my shell's UI with a gamepad?
18:34 emersion: or scroll in a web browser?
18:34 soreau: well those aren't time-critical functions
18:34 Ermine: wayland-based consoles when
18:34 soreau: but I guess if people won't complain, it's fine
18:34 colinmarc: Ermine: you mean steam?
18:34 soreau: 'I had to enable rumble in compositor settings'
18:34 emersion: they aren't time-critical functions for mice/keyboard, either
18:35 emersion: yet it's the reason why they are routed through the compositor
18:35 Ermine: colinmarc: oh yeah, but I thought about ps/xbox kind of deal
18:35 emersion: (case in point: SteamOS implements exactly this, but with hacks)
18:36 colinmarc: kind of uncharitable to call udev a hack :)
18:36 emersion: well, i have nothing against udev
18:36 colinmarc: but I also find it not great that steam has access to basically everything (plus uinput, but that's another story)
18:37 emersion: just the way SteamOS changes gamepad "focus" is… eh
18:37 soreau: are you able to get mouse/pointer events via udev?
18:37 emersion: colinmarc: in general it's not a great thing to advertise lots of globals, because all clients will see it when they connect
18:37 soreau: (as user without user in input group)
18:38 emersion: arguably having wl_output as globals was a mistake
18:38 soreau: erm.. pointer/keyboard events*
18:38 colinmarc: soreau: the other arguments for a protocol are that apps actually find it quite hard to deal with raw input. basically you have to use SDL and that is not really what you want. Plus, sometimes you are in a container or you're a remote desktop tool, and simulating/binding character devices sucks (cf my current project: https://github.com/colinmarc/southpaw)
18:39 soreau: colinmarc: so you want to solve this by importing the SDL input work into a compositor protocol API?
18:40 emersion: ideally having a libinput equivalent for gamepads
18:40 soreau: bring on the quirks
18:40 colinmarc: In rust, there's quite a good one already: https://docs.rs/gilrs/latest/gilrs/
18:41 bl4ckb0ne: i have laid out some work for a libinput for gamepad
18:41 bl4ckb0ne: https://gitlab.freedesktop.org/bl4ckb0ne/libgi
18:41 bl4ckb0ne: mostly copy pasting libinput's interface so far
18:41 bl4ckb0ne: wait i havent pushed anything
18:41 soreau: heh
18:42 bl4ckb0ne: ill push tonight
18:43 soreau: bl4ckb0ne: why not libjs? :P
18:43 soreau: or libjoystick
18:43 soreau: libgamepad
18:43 bl4ckb0ne: i just stole whot's idea with https://gitlab.freedesktop.org/libinput/libei
18:44 soreau: :P
18:44 colinmarc: 🥋
18:45 soreau: bl4ckb0ne: is it meant strictly to be consumed/used by compositors or can clients have their fun too?
18:45 bl4ckb0ne: nothing stops you from using it wherever you like
18:46 bl4ckb0ne: it just consumes udev and spats out events
18:46 soreau: because if dealing with raw input is 'hard' and SDL input is meh.. then maybe this is exactly what's needed
18:46 soreau: and side step the protocol; compositors could use it for their control and so can apps
18:46 bl4ckb0ne: i had thoughts about adding hidapi for devices that are not recognized by the kernel
18:46 bl4ckb0ne: but later
18:46 emersion: soreau: doesn't solve the focus or keybind issue
18:47 soreau: emersion: I want to play my game while it's not in focus
18:47 soreau: I don't want 'js focus'
18:47 soreau: and what keybind issue?
18:47 emersion: gamepad focus doesn't have to be the same as keyboard
18:47 soreau: emersion: but then only one app can use the device at a time?
18:47 emersion: maybe you want to configure compositor bindings based on gamepad buttons
18:48 soreau: emersion: but you could, if the compositor uses something like what bl4ckb0ne is proposing
18:48 emersion: you… use a single gamepad to control two apps at the same time?
18:48 emersion: no, because apps would react to the event as well
18:48 soreau: I see..
18:48 emersion: press home+right, character moves right
18:48 soreau: so you want to stand in the way to eat the binding
18:48 soreau: would-be binding*
18:49 emersion: but you just wanted to start the app launcher
18:49 emersion: it's really just the same as other kind of input devices
18:49 colinmarc: imo the "gamepad focus" thing is a feature, not a bug
18:49 soreau: but not according to whot :P
18:50 emersion: gamepads are a special snowflake atm, and that gets in the way of having good support for them
18:50 soreau: gamepads will always be special I think
18:50 colinmarc: I think compared to drawing tablets or whatever they're actually pretty straightforward
18:50 soreau: there's always that new feature everyone needs.. think PS4 pads with audio i/o IIRC?
18:51 soreau: and a mousepad on it, yea
18:51 kennylevinsen: I don't think gamepads *are* special in any intuitive sense, it's just that PC has a hack for support. They behave exactly as you'd expect on game consoles with focus like keyboard/mouse after all
18:51 colinmarc: soreau: right, but those don't have to go via the protocol. linux treats those as completely separate devices anyway
18:51 soreau: colinmarc: true..
18:52 colinmarc: and my ps5 controller already works as a mouse on sway. I actually am not sure how, to be honest :)
18:52 colinmarc: the touchpad, I mean
18:53 soreau: I had to disable the mousepad on my ps4 because I kept hitting it and moving the mouse while gaming
18:53 bl4ckb0ne: colinmarc: probably libinput getting it
18:53 soreau: well, back to the original issue, it seems like having some sort of manager would make sense to enumerate the devices and get events as wl events etc
18:53 soreau: instead of globals
18:54 colinmarc: if one per seat is enough, maybe there doesn't need to be a manager? just a get_gamepad(wl_seat)?
18:54 soreau: and it's nice that it has force feedback in the protocol but then what if you want to control LED's or other output
18:54 colinmarc: there's no force feedback in the protocol at the moment (or leds)
18:54 emersion: colinmarc: the get_gamepad request needs to be tied to an object
18:55 emersion: and clients need to know if a seat has gamepads connected or not
18:55 colinmarc: emersion: ah right, duh. so yeah, that would be a manager global
18:55 bl4ckb0ne: yep, gamepad plugged -> new global
18:56 soreau: colinmarc: the description at the top reads "This protocol is inspited by OpenXR input device API 1. It defines a new input device, representing a game controller, that sends events to a client and takes request to apply a haptic vibration."
18:56 soreau: I thought haptic vibration was force feedback
18:56 emersion: bl4ckb0ne: not sure one global per device is a good idea
18:56 colinmarc: bl4ckb0ne: that's what I originally brought up here, whether there should be a new global or whether the global should be a manager object that you can use to enumerate seats with gamepads and get gamepad proxies, etc. The consensus seems to be that a manager object is better.
18:57 emersion: bl4ckb0ne: see the tablet protocol, wl_pointer, etc
18:58 colinmarc: bl4ckb0ne: I could make a PR against your branch with the manager changes, so we could discuss something concrete?
18:59 bl4ckb0ne: sure
18:59 kennylevinsen: soreau: haptic vibration is a speaker with high mass, force feedback are motors that drive the joystick or steering wheel to provide things like high resistance as the car/plane fights against your input, or to make road bumps knock the wheel and such
18:59 soreau: kennylevinsen: tell that to SDL and the kernel
18:59 colinmarc: kennylevinsen: the kernel calls the former force feedback, for what its worth :)
19:00 soreau: indeed
19:00 kennylevinsen: heh
19:00 soreau: SDL uses haptic device
19:00 emersion: colinmarc: in general the registry is meant as a feature list ("here are the protocols the compositor supports"), rather than a resource list (exceptions for older interfaces)
19:00 kennylevinsen: didn't know there even was a kernel API, kind of expected it was only supported through hidraw as a HID output report or something
19:00 colinmarc: that was my intuition as well, glad to have it confirmed
19:01 colinmarc: kennylevinsen: https://www.kernel.org/doc/Documentation/input/event-codes.txt
19:01 colinmarc: see the section on FF_* events
19:02 colinmarc: what I don't 100% understand is that they seem to work both by writing to the device file and by doing a FF ioctl
19:03 soreau: colinmarc: what do you mean by writing to the device file? like echo garbage > /dev/input/js0?
19:04 colinmarc: the evdev file, which is different, I think (/dev/input/event123)
19:04 soreau: and this triggers a rumble on+off sequence?
19:04 colinmarc: yes
19:04 soreau: huh
19:04 soreau: that's interesting
19:05 soreau: oh yea, fftest uses the event node
19:05 colinmarc: you write some C-abi structs to it: https://github.com/torvalds/linux/blob/master/include/uapi/linux/input.h#L454-L468
19:05 kennylevinsen: modern controller rumble isn't on/off, it's a waveform, but it does seem that there is support for thta
19:05 kennylevinsen: https://www.kernel.org/doc/Documentation/input/ff.rst
19:05 soreau:remembering his custom hw project to replace N64 mobo to interface 4 controllers via parallel port with force feedback using gamecon kernel driver
19:06 colinmarc: kennylevinsen: when you say waveform, is it like audio where you send raw samples to the device? at what frequency?
19:06 colinmarc: sorry, this is slightly off topic, but that's something I've been wondering about
19:06 soreau: kennylevinsen: there is a waveform but it's on/off
19:07 soreau: at least, that's how the kernel sees it afaik
19:08 soreau: colinmarc: I think it's on-topic because we're talking about things related to wayland protocol details *shrug*
19:09 soreau: kennylevinsen: FF_PERIODIC is the type where there's a 'subtype' of a waveform, would be programmed in the driver if the device supports it
19:09 soreau: and there'
19:09 colinmarc: when I saw that, I assumed there was a "player" somewhere creating samples to send to the device based on that higher level instruction set
19:10 soreau: (and there's fftest and jstest clients that are barebones examples of how to use the kernel ioctls)
19:11 soreau: I remember when I found the codes to do rumble on N64 pads, I didn't write the 'off' part yet, so when it worked for the first time.. it never stopped
19:11 kennylevinsen: https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering/issues/11#issuecomment-360379786
19:11 soreau: kennylevinsen: but to 'throttle' ff, the client sends multiple on/off
19:12 kennylevinsen: that talks about the stuff in switch HD Rumble, which is supplyed by https://www.immersion.com/ to both switch and ps5
19:14 kennylevinsen: seems like you can program a few primitives at once to composite the final effect
19:14 colinmarc: kennylevinsen: so the player is actually a microcontroller inside the device, iiuc? that's interesting
19:15 kennylevinsen: at least on the switch you might have 8 joycons attached all with their own haptics, might be a bit much if they all had to receive an audio stream to power the rumble :P
19:16 kennylevinsen: but not sure if this information is complete
19:16 kennylevinsen: regardless, it might be that the kernel API for actual haptics vibration is insufficient
19:16 soreau: kennylevinsen: I think it's more about on-with-particular-hw-supported-effect and on-off-to-throttle-devices-that-only-support-on-and-off
19:17 soreau: bl4ckb0ne: should be libjsio :P
19:18 bl4ckb0ne: when i originally named the protocol "joystick" i got so much backlash on it
19:19 soreau: bl4ckb0ne: but really, how would the rumble event be routed through the compositor, where would it end up? in the input lib to do output?
19:19 soreau: or some other means
19:19 kennylevinsen:has never really been able to take the name "joystick" seriously for an input device
19:19 soreau: kennylevinsen: but they're so much *fun*
19:19 soreau: hence the joy ;)
19:19 bl4ckb0ne: i think somewhere in the bikeshed i said I'd tackle that in a follow up protocol
19:19 soreau: bl4ckb0ne: but how would it work?
19:19 bl4ckb0ne: mostly because its a large subject
19:20 soreau: like you'd have to kinda mirror the kernel API I suppose?
19:20 bl4ckb0ne: probably enumerate haptic sources, match whatever controller you have
19:20 bl4ckb0ne: could be part of libgi maybe
19:20 soreau: but that's input per the name ;)
19:20 soreau: heh
19:20 FreeFull: Joysticks used to be these big, lengthy things
19:20 FreeFull: Now they're little nubbins
19:20 bl4ckb0ne: or something very simple in the game-controller protocol, but modern gamepad are so complex
19:21 bl4ckb0ne: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/244#note_2310811
19:21 soreau: with SDL haptic interface, they just kinda mask the kernel API to provide something generic IIRC
19:22 colinmarc: my ps5 controller only supports:... (full message at <https://matrix.org/oftc/media/v1/media/download/AUdfRcpdxyLCUyssmh5w3vumw47HxDkeqTySQOM1xRf8ilN0Yu5-I3lBG2JnwmxOFVnz_QqJiqkifxsy0ir_oy1CeSEpnlLAAG1hdHJpeC5vcmcvTkJBR1d3T01aVlpHa3JBaWVlWElBWVB2>)
19:22 bl4ckb0ne: my base was openxr https://registry.khronos.org/OpenXR/specs/1.1/html/xrspec.html#input-output-actions-haptics
19:22 bl4ckb0ne: but people dont like it
19:23 soreau: bl4ckb0ne: I'd be really disappointed if the protocol didn't support haptic/ff requests
19:23 colinmarc: one major question I had that got lost in the thread, I think, was whether wine-on-wayland would be able to use the protocol
19:23 kennylevinsen: I guess that question bceomes "can it translate to xinput/directinput"
19:23 soreau: colinmarc: why wouldn't it be able to?
19:24 soreau: just because it has to be plumbed in the wine?
19:25 colinmarc: because I think wine uses hidraw, based on this diagram: https://github.com/GloriousEggroll/proton-ge-custom/blob/master/docs/CONTROLLERS.md
19:26 soreau: sounds like their problem to solve :P
19:26 soreau: once there is an available API that serves as a replacement, they might try it
19:26 colinmarc: yeah, but if it's not possible that removes 95% of the utility of the protocol, unfortunately. so it would be good to know
19:27 colinmarc: (95% because 95% of games on linux run through wine)
19:27 soreau: sounds like a chicken-n-egg problem
19:27 colinmarc: if it's just a matter of effort, yes. I don't really understand how low-level xinput is, and whether it would be able to map to the protocol
19:27 soreau: in this case, it makes sense for the protocol to come first, it could be disabled in compositor settings or whatever so the device is left to be used by apps
19:27 bl4ckb0ne: soreau: im thinking more and more about bringing back a very dumb haptic feedback
19:28 soreau: bl4ckb0ne: do tell more
19:28 bl4ckb0ne: but some controllers have 2 motors that you can vibrate independantly
19:29 bl4ckb0ne: see https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/244#note_2055801
19:31 soreau: bl4ckb0ne: I don't think it's safe to assume 2
19:31 soreau: or any number
19:31 bl4ckb0ne: yeah
19:31 bl4ckb0ne: but then you need to enumerate the sources, give proper control, etc
19:31 bl4ckb0ne: so thats why i wanted a dedicated protocol
19:32 colinmarc: imo the basic version is useful and covers 99% of gamepads that people have. the basic version is just (duration, waveform, gain).
19:32 soreau: what's wrong with enumeration of outputs for the device?
19:33 soreau: I mean you already have to do the same for axis/buttons
19:38 soreau: and even if the device has more than one output for ff, it's up to the driver to group them as one or expose them independently..
19:38 bl4ckb0ne: its yet another interface to write and handle
19:38 soreau: and looking at the docs for kernel FF, I'm not sure it supports more than two (strong/weak)
19:39 bl4ckb0ne: i think i even removed the source enumeration
19:39 soreau: bl4ckb0ne: but gamers will thank you (or complain loudly when they notice something isn't working right)
19:40 soreau: maybe a driver could expose each ff output as a separate event node, but idk
19:40 bl4ckb0ne: i need to look at ff more
19:41 soreau: please do :|
20:22 colinmarc: bl4ckb0ne: sorry for more bikeshedding, but what about gamepad vs game controller? It's one word vs two
20:24 bl4ckb0ne: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/244#note_2050834
20:24 colinmarc: just noticed that while working on the MR for the manager stuff
20:24 colinmarc: right, that discusses "joystick", but I'm expressing a preference for "gamepad" ;)
20:25 kennylevinsen:throws in "game controller"
20:26 bl4ckb0ne: iirc it was mostly to extend to whatever funky aircraft simulator controller there is out there
20:26 bl4ckb0ne: and keep v1 for the "regular" controllers
20:26 bl4ckb0ne: https://en.wikipedia.org/wiki/List_of_game_controllers
20:27 bl4ckb0ne: like most of what's in that list
20:27 bl4ckb0ne: which follow the same "pattern" more or less
20:27 bl4ckb0ne:looks at the wiimote
20:28 colinmarc: kennylevinsen: that's what it currently is
20:28 kennylevinsen: I don't think I have ever called the types of handheld game controllers in question anything other than "controller" or "game controller"
20:29 colinmarc: what, you don't refer to them by their brand names? I'm quite fond of my Sony Wireless DualSense
20:29 kennylevinsen: colinmarc: yeah I realize that now, I just got caught up in joystick and gamepad (only one of those two is actually a used term IMO, and it refers to a flight stick specifically)
20:29 bl4ckb0ne: but if you want to reopen the discussion, feel free to post in the thread
20:29 kennylevinsen: Sony Playstration® 3 SIXAXIS DualShock 3™
20:30 kennylevinsen: bl4ckb0ne: +1 for game controller
20:30 colinmarc: kk, bikeshed concluded :)
20:31 bl4ckb0ne: https://en.wikipedia.org/wiki/Nights_into_Dreams#/media/File:Sega-Saturn-3D-Controller.jpg is it still a game controller if you can also use it as a frisbee
20:35 kennylevinsen: it's a tie between that and the n64 controller, no need to support anything else
20:37 bl4ckb0ne: and the wii nunchuck ofc
22:16 kode54: mehdix: https://github.com/labwc/labwc/issues/2130
22:16 kode54: maybe they won't even see that
22:16 kode54: they somehow don't have history feed turned on
22:21 soreau: bl4ckb0ne: further, since most programs assume they can use strong rumble and feather the strength by using some duty cycle of on/off, sending this through the compositor doesn't make sense, because having such noise on the wire is probably bad for business [TM]
22:23 soreau: maybe you can do the feathering in the compositor, and expose some interface that allows the client to set the strength and duration or so, but then what stops them from just wiring it up to what they're doing now and flood the socket
22:23 soreau: might be a good idea to looks at sdl haptic api..
22:24 soreau: see what they came up with
22:24 riteo: just chiming in, SDL is definitely the closest thing we have to prior art
22:25 riteo: great knowing that this stuff is being brought up! I'm really interested into seeing this come into fruition
22:25 riteo: (wait is that the word)
22:26 kennylevinsen: there's also prior art in xinput/directinput/steam's input stuff
22:31 soreau: https://github.com/libsdl-org/SDL/blob/main/include/SDL3/SDL_haptic.h
22:31 soreau: it even has ascii art, heh
22:34 riteo: nice
23:22 wlb: wayland-protocols Merge request !336 opened by () Add data-control protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/336
23:30 soreau: any1: didn't we just go through this ^^? :P
23:31 soreau: not sure if they don't know of wl-clipboard or what
23:31 soreau: oh it's a s/wlr/ext/