ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
RAOF has quit [Remote host closed the connection]
<eruditehermit>
I just learned that there is a separate DE and display server clipboard. What is the best way to sync them in KDE?
ploutos has quit [Remote host closed the connection]
<eruditehermit>
nvm I found the setting
glennk has quit [Ping timeout: 480 seconds]
<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 &
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Remote host closed the connection]
PorkrollPosadist has quit [Quit: WeeChat 4.3.4]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
MrCooper has quit [Read error: Connection reset by peer]
MrCooper has joined #wayland
yshui has quit [Remote host closed the connection]
yshui has joined #wayland
eruditehermit has quit [Quit: Konversation terminated!]
yshui has quit [Remote host closed the connection]
yshui has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
mxz__ has joined #wayland
yshui has quit [Remote host closed the connection]
mxz has quit [Ping timeout: 480 seconds]
yshui has joined #wayland
mxz_ has quit [Ping timeout: 480 seconds]
mxz__ is now known as mxz
mxz_ has joined #wayland
kts has joined #wayland
kts has quit []
kts has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
bindu has quit [Read error: Connection reset by peer]
bindu has joined #wayland
navi has quit [Read error: Connection reset by peer]
navi has joined #wayland
kts has quit [Quit: Leaving]
glennk has joined #wayland
<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)
sima has joined #wayland
<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
rasterman has joined #wayland
mehdix has joined #wayland
<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?
<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.
<mehdix>
The OS is Arch Linux with AMD CPU and GPU.
<dottedmag>
mehdix: It might be anywhere in the stack from FF to kernel. Please do file a bug report in Firefox bugtracker
<soreau>
it also could be seatd not telling wlroots to stop rendering, I have a similar issue
<mehdix>
dottedmag, I want to gather useful information on the bug before filing it.
<soreau>
with wayfire though - if I switch to a tty, wayfire on the other tty takes 100+% cpu
<mehdix>
soreau, that's interesting. since sometimes I notice switching back immediately stops the gpu usage back to close to zero
<mehdix>
dottedmag, bty, firefox bug tracker is such a graveyard. I have bugs with details hanging there since years...
<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
<soreau>
cc kennylevinsen ^^
<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.
<soreau>
I previously thought that upgrading seatd fixed things but the bug keeps coming back still
<mehdix>
It's bothering me for over a year now (probably since I switched to using to sessions).
<soreau>
I login with a dm, but test on another tty and the issue is obvious
<mehdix>
soreau, have you filed a bug for it? Since you can apparently very accurately reproduce it.
<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
<soreau>
mehdix: only mentioned it to kenny :P
<soreau>
they put up a logind-debug branch to output more info
<soreau>
of seatd
<mehdix>
I use no dms and it happens every single day.
<kode54>
I log in with a DM too
<soreau>
but sadly, I have not used that branch to find out more yet :P
<kode54>
but I use uwsm through a custom .desktop file
<kode54>
since I use GDM, I also get automatically logged into gnome keyring
<kode54>
gnome keyring is my preferred gpg secrets holder, too, because it lets me save the passkey to my keychain
<kode54>
I also use libsecret cli tool to store my email passwords for notmuch syncing
<kode54>
</offtopic>
<kode54>
mehdix: firefox does other stupid crap here with a single labwc instance
<kode54>
when I had my mixed 2.0 / 1.0 scale monitors setup
<kode54>
the 2.0 monitor has a firmware bug where it disconnects itself momentarily whenever it turns on or wakes from DPMS state
<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")
<kode54>
kanshi then resets the scale to 2.0
<kode54>
I reproduced it with booting an instance of labwc, then manually setting the output scale to 2.0
<kode54>
firefox will have sizing issues that become apparent when another window overlaps the top left corner of the firefox window
<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
<kode54>
or if the top left corner of the window is moved outside the screen
<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
<kode54>
and other parts of the UI glitch out rapidly
<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?
<kode54>
it ceases if the corner of the window is made visible again
<kode54>
I filed my issue with labwc
<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 :-)
<kode54>
it probably should be filed with firefox too
<kode54>
dottedmag: what do you do when one output momentarily hops the bus?
<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)
<kode54>
my current setup has two 1.0 scale screens
<kode54>
and both of them remain firmly attached to their ports when power cycled
<kode54>
alas, now I have another issue, VRR doesn't work with the HDMI one
<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.
<kode54>
I have another nag with quartz and detaching monitors
<kode54>
it forgets what refresh rate you set before it detached
<kode54>
so my stupid 4k VRR panel can't be kept in VRR mode
<kode54>
thanks, Apple
<mehdix>
kode54, just tried and on Sway I have not that issue. Window overlapping work flawlessly.
<kode54>
mehdix: as I filed it as a labwc issue
<dottedmag>
kode54: Amen. I guess you have already tried hammerspooning it?
<kode54>
hammerspooning it?
<kode54>
I'll look into that next time I find my USB-C to DP cable
<mehdix>
soreau, thanks for the link, will definitely do that! I came here to understand which component is causing the issue.
<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.
<dottedmag>
Sorry, </offtopic>
<mehdix>
kode54, would you mind posting the link?
<soreau>
mehdix: np, I might try it as well when I have some gumption to do it
<kode54>
mehdix: which one?
<kode54>
I only reported it for labwc, the issue is the github link above
<mehdix>
kode54, sorry was testing seatd and was logged out (can't see older messages even though I have a znc...)
<mehdix>
good news is, I enabled seatd service in Arch and so far I have not hit the aforementioned bug
paulk-bis has joined #wayland
paulk has quit [Read error: Connection reset by peer]
Company has joined #wayland
vnd has joined #wayland
<vnd>
Hey guys, hope you can save my arse, so to speak.
<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.
<vnd>
There's a FullHD display connected, natively in landscape mode, but must be used in portrait mode.
<vnd>
So it's rotated in weston.ini (transform=270).
<vnd>
Now the problem: higher resolution video (about half of FullHD, occupying half of the screen) is very teared/jerky.
<vnd>
FPS by itself is not an issue, reported around 30 by fpsdisplaysink.
<vnd>
Now if display rotation is disabled (transform=0), video is smooth.
<vnd>
Video is played via gst-launch-1.0 with waylandsink.
<vnd>
I've backported "rotate-method" waylandsink support, which effectively calls wl_surface_set_buffer_transform(), among other things.
<vnd>
The idea was to match weston rotation and video rotation so that they cancel out.
<vnd>
The commit didn't apply cleanly, but I think I've figured it out and ported properly.
<vnd>
Video is indeed rotated, but still teared/jerky.
<vnd>
Any ideas? Anywhere to look in particular? At this point not even fully sure if it's more about weston, or gstreamer.
<vnd>
Any ugly workaround would do, basically I need to make weston not rotate the video, as it will pre-rotated already.
fmuellner has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
vnd has quit [Remote host closed the connection]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
fmuellner has quit []
fmuellner has joined #wayland
<kennylevinsen>
mehdix: I need to put out a bugfix release at some point, the issue is fixed in master
<kennylevinsen>
(for libseat)
<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
<bluetail>
granted to users in group input by a udev rule."
<kennylevinsen>
bluetail: your user should never be in group input, that would undermine all input eavesdropping security :/
___nick___ has joined #wayland
<bluetail>
maybe I should tell gebby, the author of dotool. They explicitly state it.
<kennylevinsen>
are you sure your user isn't in the input group? run `groups`
<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.
<kennylevinsen>
maybe you installed something else that also had a uinput udev rule
<kennylevinsen>
yup, then that's why it works for you
<kennylevinsen>
uaccess tells logind to give access to any logged in user on top of the normal posix permissions using ACLs
<bluetail>
wait but ctrl+f => steam ... ? so steam is the cause for this?
<bluetail>
if you know, can you please state which application is the cause
<kennylevinsen>
you just sent the link yourself, antimicrox
<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.
<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
nysach has joined #wayland
<bluetail>
I don't quite like that. Should I post a issue on antimicrox?
nysach has quit [Remote host closed the connection]
DodoGTA has quit [Remote host closed the connection]
DodoGTA has joined #wayland
<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
<bluetail>
I see. Thanks
kts has joined #wayland
kts has quit []
fmuellner has quit [Remote host closed the connection]
fmuellner has joined #wayland
nerdopolis has joined #wayland
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
feaneron has joined #wayland
kts has joined #wayland
vnd has joined #wayland
vnd_ has joined #wayland
vnd2 has joined #wayland
vnd has quit [Quit: Page closed]
vnd2 is now known as vnd
Moprius has joined #wayland
Moprius has quit [Remote host closed the connection]
<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
Brainium has quit [Quit: Konversation terminated!]
ploutos has joined #wayland
ploutos has quit [Remote host closed the connection]
ploutone has joined #wayland
kts has quit [Quit: Leaving]
cyrinux has quit []
cyrinux has joined #wayland
colinmarc has joined #wayland
<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?
<emersion>
might not need all of that complexity if you don't need more than one object per seat
<soreau>
but for apps, they can usually get joystick events from another means than piping them through the compositor first?
<colinmarc>
soreau yes, but that's what the proposed protocol would change
<soreau>
well it does sound like a manager for events would be easier to manage than trying to keep up with globals..
<soreau>
but I don't really understand the reason for the proposed change
<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)
<soreau>
seems like you'd have extra hops between your input and the game app..
<soreau>
and people wouldn't want this
<emersion>
soreau: and it's fine for keyboards?
<soreau>
emersion: well for keyboards, you need to dispatch the events to 'a client' that has 'keyboard focus', right?
<emersion>
why should gamepads be different?
<colinmarc>
mice is actually the one where people really care about latency, usually, and that also goes over wayland
<emersion>
why shouldn't i be able to navigate around in my shell's UI with a gamepad?
<emersion>
or scroll in a web browser?
<soreau>
well those aren't time-critical functions
<Ermine>
wayland-based consoles when
<soreau>
but I guess if people won't complain, it's fine
<colinmarc>
Ermine: you mean steam?
<soreau>
'I had to enable rumble in compositor settings'
<emersion>
they aren't time-critical functions for mice/keyboard, either
<emersion>
yet it's the reason why they are routed through the compositor
<Ermine>
colinmarc: oh yeah, but I thought about ps/xbox kind of deal
<emersion>
(case in point: SteamOS implements exactly this, but with hacks)
<colinmarc>
kind of uncharitable to call udev a hack :)
<emersion>
well, i have nothing against udev
<colinmarc>
but I also find it not great that steam has access to basically everything (plus uinput, but that's another story)
<emersion>
just the way SteamOS changes gamepad "focus" is… eh
<soreau>
are you able to get mouse/pointer events via udev?
<emersion>
colinmarc: in general it's not a great thing to advertise lots of globals, because all clients will see it when they connect
<soreau>
(as user without user in input group)
<emersion>
arguably having wl_output as globals was a mistake
<soreau>
erm.. pointer/keyboard events*
<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)
<soreau>
colinmarc: so you want to solve this by importing the SDL input work into a compositor protocol API?
<emersion>
ideally having a libinput equivalent for gamepads
<soreau>
bl4ckb0ne: is it meant strictly to be consumed/used by compositors or can clients have their fun too?
<bl4ckb0ne>
nothing stops you from using it wherever you like
<bl4ckb0ne>
it just consumes udev and spats out events
<soreau>
because if dealing with raw input is 'hard' and SDL input is meh.. then maybe this is exactly what's needed
<soreau>
and side step the protocol; compositors could use it for their control and so can apps
<bl4ckb0ne>
i had thoughts about adding hidapi for devices that are not recognized by the kernel
<bl4ckb0ne>
but later
<emersion>
soreau: doesn't solve the focus or keybind issue
<soreau>
emersion: I want to play my game while it's not in focus
<soreau>
I don't want 'js focus'
<soreau>
and what keybind issue?
<emersion>
gamepad focus doesn't have to be the same as keyboard
<soreau>
emersion: but then only one app can use the device at a time?
<emersion>
maybe you want to configure compositor bindings based on gamepad buttons
<soreau>
emersion: but you could, if the compositor uses something like what bl4ckb0ne is proposing
<emersion>
you… use a single gamepad to control two apps at the same time?
<emersion>
no, because apps would react to the event as well
<soreau>
I see..
<emersion>
press home+right, character moves right
<soreau>
so you want to stand in the way to eat the binding
<soreau>
would-be binding*
<emersion>
but you just wanted to start the app launcher
<emersion>
it's really just the same as other kind of input devices
<colinmarc>
imo the "gamepad focus" thing is a feature, not a bug
<soreau>
but not according to whot :P
<emersion>
gamepads are a special snowflake atm, and that gets in the way of having good support for them
<soreau>
gamepads will always be special I think
<colinmarc>
I think compared to drawing tablets or whatever they're actually pretty straightforward
<soreau>
there's always that new feature everyone needs.. think PS4 pads with audio i/o IIRC?
<soreau>
and a mousepad on it, yea
<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
<colinmarc>
soreau: right, but those don't have to go via the protocol. linux treats those as completely separate devices anyway
<soreau>
colinmarc: true..
<colinmarc>
and my ps5 controller already works as a mouse on sway. I actually am not sure how, to be honest :)
<colinmarc>
the touchpad, I mean
<soreau>
I had to disable the mousepad on my ps4 because I kept hitting it and moving the mouse while gaming
<bl4ckb0ne>
colinmarc: probably libinput getting it
<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
<soreau>
instead of globals
<colinmarc>
if one per seat is enough, maybe there doesn't need to be a manager? just a get_gamepad(wl_seat)?
<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
<colinmarc>
there's no force feedback in the protocol at the moment (or leds)
<emersion>
colinmarc: the get_gamepad request needs to be tied to an object
<emersion>
and clients need to know if a seat has gamepads connected or not
<colinmarc>
emersion: ah right, duh. so yeah, that would be a manager global
<bl4ckb0ne>
yep, gamepad plugged -> new global
<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."
<soreau>
I thought haptic vibration was force feedback
<emersion>
bl4ckb0ne: not sure one global per device is a good idea
<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.
<emersion>
bl4ckb0ne: see the tablet protocol, wl_pointer, etc
<colinmarc>
bl4ckb0ne: I could make a PR against your branch with the manager changes, so we could discuss something concrete?
<bl4ckb0ne>
sure
<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
<soreau>
kennylevinsen: tell that to SDL and the kernel
<colinmarc>
kennylevinsen: the kernel calls the former force feedback, for what its worth :)
<soreau>
indeed
<kennylevinsen>
heh
<soreau>
SDL uses haptic device
<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)
<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
<colinmarc>
that was my intuition as well, glad to have it confirmed
* soreau
remembering his custom hw project to replace N64 mobo to interface 4 controllers via parallel port with force feedback using gamecon kernel driver
<colinmarc>
kennylevinsen: when you say waveform, is it like audio where you send raw samples to the device? at what frequency?
<colinmarc>
sorry, this is slightly off topic, but that's something I've been wondering about
<soreau>
kennylevinsen: there is a waveform but it's on/off
<soreau>
at least, that's how the kernel sees it afaik
feaneron has quit [Ping timeout: 480 seconds]
<soreau>
colinmarc: I think it's on-topic because we're talking about things related to wayland protocol details *shrug*
<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
<soreau>
and there'
<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
<soreau>
(and there's fftest and jstest clients that are barebones examples of how to use the kernel ioctls)
<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
<soreau>
kennylevinsen: but to 'throttle' ff, the client sends multiple on/off
<kennylevinsen>
that talks about the stuff in switch HD Rumble, which is supplyed by https://www.immersion.com/ to both switch and ps5
<kennylevinsen>
seems like you can program a few primitives at once to composite the final effect
<colinmarc>
kennylevinsen: so the player is actually a microcontroller inside the device, iiuc? that's interesting
<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
<kennylevinsen>
but not sure if this information is complete
<kennylevinsen>
regardless, it might be that the kernel API for actual haptics vibration is insufficient
<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
<soreau>
bl4ckb0ne: should be libjsio :P
<bl4ckb0ne>
when i originally named the protocol "joystick" i got so much backlash on it
yshui has quit [Ping timeout: 480 seconds]
<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?
<soreau>
or some other means
* kennylevinsen
has never really been able to take the name "joystick" seriously for an input device
<soreau>
kennylevinsen: but they're so much *fun*
<soreau>
hence the joy ;)
<bl4ckb0ne>
i think somewhere in the bikeshed i said I'd tackle that in a follow up protocol
<soreau>
bl4ckb0ne: but how would it work?
<bl4ckb0ne>
mostly because its a large subject
<soreau>
like you'd have to kinda mirror the kernel API I suppose?
<bl4ckb0ne>
probably enumerate haptic sources, match whatever controller you have
<bl4ckb0ne>
could be part of libgi maybe
<soreau>
but that's input per the name ;)
<soreau>
heh
<FreeFull>
Joysticks used to be these big, lengthy things
<FreeFull>
Now they're little nubbins
<bl4ckb0ne>
or something very simple in the game-controller protocol, but modern gamepad are so complex
<soreau>
once there is an available API that serves as a replacement, they might try it
<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
<colinmarc>
(95% because 95% of games on linux run through wine)
<soreau>
sounds like a chicken-n-egg problem
<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
<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
<bl4ckb0ne>
soreau: im thinking more and more about bringing back a very dumb haptic feedback
<soreau>
bl4ckb0ne: do tell more
<bl4ckb0ne>
but some controllers have 2 motors that you can vibrate independantly
<bl4ckb0ne>
which follow the same "pattern" more or less
* bl4ckb0ne
looks at the wiimote
yshui has quit [Ping timeout: 480 seconds]
<colinmarc>
kennylevinsen: that's what it currently is
<kennylevinsen>
I don't think I have ever called the types of handheld game controllers in question anything other than "controller" or "game controller"
<colinmarc>
what, you don't refer to them by their brand names? I'm quite fond of my Sony Wireless DualSense
<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)
<bl4ckb0ne>
but if you want to reopen the discussion, feel free to post in the thread
<kennylevinsen>
Sony Playstration® 3 SIXAXIS DualShock 3™
<kode54>
they somehow don't have history feed turned on
<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]
<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
<soreau>
might be a good idea to looks at sdl haptic api..
<soreau>
see what they came up with
<riteo>
just chiming in, SDL is definitely the closest thing we have to prior art
<riteo>
great knowing that this stuff is being brought up! I'm really interested into seeing this come into fruition
<riteo>
(wait is that the word)
<kennylevinsen>
there's also prior art in xinput/directinput/steam's input stuff