|
akadajet posted:rolling your fingers across inputs to increase your odds of performing an action. you know, something that will cause inputs to maybe overlap i feel like using lovely usb membrane keyboards for like 20 years has conditioned me against doing this
|
#
?
Jan 16, 2023 23:06
|
|
|
|
| # ? Apr 20, 2024 05:15 |
|
|
Beeftweeter posted:i feel like using lovely usb membrane keyboards for like 20 years has conditioned me against doing this it's a very satisfying thing to do on a stick but thinking about doing it on a keyboard makes me uneasy
|
|
#
?
Jan 16, 2023 23:07
|
|
|
mycophobia posted:it's a very satisfying thing to do on a stick but thinking about doing it on a keyboard makes me uneasy with a keyboard you can have 2 players with the same input device
|
|
#
?
Jan 16, 2023 23:13
|
|
|
i guess if my hands were smaller i'd probably have attempted it more, but i've never really had a problem hitting something at the time i wanted to. it always seemed pretty obvious that rollover didn't work correctly, especially playing older racing games with a newer keyboardakadajet posted:with a keyboard you can have 2 players with the same input device i mean, i guess. maybe it's the hand size thing again but afaik i never really did this either, most two-player things are turn based
|
|
#
?
Jan 16, 2023 23:22
|
|
|
yeah, the lovely, rusty old IBM n-key rollover keyboard was superior to p. much everything else when we were playing games with family when i was a kid. all the new shiny cheap keyboards were like 4-6 keys and then speaker would start to beep i still use an ancient ps/2 n-key rollover keyboard now because videogames. still remember the kid me doing strafe+forward+run+jump in q2 and then want to swap weapon and speaker goes beep beep beep oh i'm dead lmfao i guess modern keyboards do a custom device over USB now to do that but lol
|
|
#
?
Jan 16, 2023 23:30
|
|
|
Beeftweeter posted:that's... exactly what those do But they run TOS in an emulator (which is of course very neat). quote:
I thought Captain Pike fucked around with this message at 00:43 on Jan 17, 2023 |
|
#
?
Jan 17, 2023 00:13
|
|
|
that was eschaton, not me, but i get your point. i don't really know enough about the various TOS offshoots to comment, but GEM is open source and has been for a really long time. some of the projects like hatari seem capable of doing at least some of that unless you're looking for a GEM-like window manager? i haven't really looked for one and wouldn't even know where to start, but i'd be surprised if one didn't exist
|
|
#
?
Jan 17, 2023 00:31
|
|
|
The kernel has a big hardcoded table of HID fixes and workarounds because "the executable binary of HID.SYS from Windows 10 or whatever" is the only actual specification that matters. Maybe something in there broke in a version of the kernel that is newer than what Debian is carrying. There is a recent project to move that table out into BPF programs supplied from userspace so that these workarounds can be fixed faster than a typical kernel release cycle. But I don't think this mechanism has actually landed in any distribution kernel yet.
|
|
#
?
Jan 17, 2023 01:29
|
|
|
pseudorandom name posted:gamer keyboards implement N-key rollover by using a custom HID report descriptor that includes every single key instead of the HID Boot Protocol that can only do 6 plus modifiers; I wonder if there’s is particularly hosed up or if they do something stupid where they present a HID BP descriptor to the UEFI firmware and the. do a mode change when it detects windows and they’ve messed that up somehow color me surprised that gamer keyboards need specialized n-key implementations
|
|
#
?
Jan 17, 2023 02:53
|
|
|
my homie dhall posted:color me surprised that gamer keyboards need specialized n-key implementations nah, its HID HID is arbitrarily complex, too complex for a PC BIOS in 1996 to parse, so they defined three minor device classes -- generic devices that could be anything and require a full report descriptor parser to understand, and Boot Protocol Keyboards & Boot Protocol Mice Boot Protocol devices don't even have HID Report descriptors, they implicitly use descriptors defined in the spec, and the keyboard descriptor defines 8 byte packets -- 6 one bye key codes, 8 one bit modifiers, and a padding byte. for a long while it was impossible to get N-key rollover in USB HID so the gamers stayed with their PS2 keyboards, but eventually keyboard manufacturers started designing their own keyboard controllers which are generic HID devices that define reports large enough for every key on the keyboard simultaneously except now you have the problem that your keyboard is using custom HID reports that your PC BIOS from 1996 can't understand, so there's generally something stupid involved in starting up as a Boot Protocol Keyboard and then switching to the N-key mode after the OS starts edit: oh, and they way that it is supposed to work is that the keyboard comes up in normal full-featured mode and then the BIOS has to manually send a Set_Protocol request to switch it into Boot Protocol mode, except nobody implemented non-Boot Protocol keyboards for a while and as you can imagine all BIOSes are poo poo pseudorandom name fucked around with this message at 04:15 on Jan 17, 2023 |
|
#
?
Jan 17, 2023 04:07
|
|
|
wonder if its possible to implement an EFI DXE driver for something like that i doubt anyone would go through the effort but i don't see why not
|
|
#
?
Jan 17, 2023 04:21
|
|
|
If the bioses can't handle generic hid devices couldn't the keyboard just act as two devices, one boot protocol and one generic, and then disable the boot protocol device once the os starts polling the generic device or something?
|
|
#
?
Jan 17, 2023 04:27
|
|
|
pretty sure that's the most detailed and technically sound reply ever written to a 'gamers sure do say the forbidden word a whole lot' goof i've ever seen. impressive
|
|
#
?
Jan 17, 2023 04:27
|
|
|
mystes posted:If the bioses can't handle generic hid devices couldn't the keyboard just act as two devices, one boot protocol and one generic, and then disable the boot protocol device once the os starts polling the generic device or something? i think that's pretty much what pseudorandom was talking about
|
|
#
?
Jan 17, 2023 04:33
|
|
|
pseudorandom name posted:nah, its HID whoosh
|
|
#
?
Jan 17, 2023 04:39
|
|
|
mycophobia posted:anyways im just being a dick for no reason, sorry. not a good thing to try to derive joy from I still remember id software games with the "nojoy" option but it just meant no joystick who even plays doom with a joystick though
|
|
#
?
Jan 17, 2023 04:48
|
|
|
Beeftweeter posted:i think that's pretty much what pseudorandom was talking about I was wondering if instead it would be possible to work around the problem on the side of the keyboard.
|
|
#
?
Jan 17, 2023 04:49
|
|
|
akadajet posted:with a keyboard you can have 2 players with the same input device I think the best game with keyboard multiplayer has got to be star control 2 melee
|
|
#
?
Jan 17, 2023 04:51
|
|
|
BattleMaster posted:whoosh seriously
|
|
#
?
Jan 17, 2023 04:56
|
|
|
pseudorandom name posted:nah, its HID hint: dhall was making a “gamer word” joke
|
|
#
?
Jan 17, 2023 05:00
|
|
|
mystes posted:I might be misunderstanding but the only part that seemed to address compatibility workarounds was the last part ("edit: oh, and they way that it is supposed to work is that the keyboard comes up in normal full-featured mode and then the BIOS has to manually send a Set_Protocol request to switch it into Boot Protocol mode, except nobody implemented non-Boot Protocol keyboards for a while and as you can imagine all BIOSes are poo poo") but that seemed to be saying that it's the bios's responsibility to signal the keyboard to switch into the boot protocol mode and bioses fail to do that. i'm not certain since it's not quite my wheelhouse (i have worked on EFI stuff before but not really USB) but i think they do this already by implementing their own controller. i know there's at least a mode switch in peripheral support when booting (on both EFI and BIOS; full USB support is not typically implemented or necessary) and that can be communicated to devices, but i don't know if these keyboards specifically do this. i would not be surprised though
|
|
#
?
Jan 17, 2023 05:02
|
|
|
Voodoo Cafe posted:pretty sure that's the most detailed and technically sound reply ever written to a 'gamers sure do say the forbidden word a whole lot' goof i've ever seen. impressive normal people don't spend their time thinking about racist slurs my dude
|
|
#
?
Jan 17, 2023 05:18
|
|
|
my homie dhall posted:color me surprised that gamer keyboards need specialized n-key implementations lmao
|
|
#
?
Jan 17, 2023 05:20
|
|
|
pseudorandom name posted:nah, its HID wish you HID t hi s post 
|
|
#
?
Jan 17, 2023 05:21
|
|
|
pseudorandom name posted:normal people don't spend their time thinking about racist slurs my dude You missed a pretty obvious joke, take it on the chin
|
|
#
?
Jan 17, 2023 05:21
|
|
|
mystes posted:I might be misunderstanding but the only part that seemed to address compatibility workarounds was the last part ("edit: oh, and they way that it is supposed to work is that the keyboard comes up in normal full-featured mode and then the BIOS has to manually send a Set_Protocol request to switch it into Boot Protocol mode, except nobody implemented non-Boot Protocol keyboards for a while and as you can imagine all BIOSes are poo poo") but that seemed to be saying that it's the bios's responsibility to signal the keyboard to switch into the boot protocol mode and bioses fail to do that. yeah, that's the point of this whole conversation -- the original question was how could a keyboard gently caress things up so badly it doesn't work and the answer is there's a decent chance that gamer keyboards have weird heuristics specifically to work around this issue
|
|
#
?
Jan 17, 2023 05:23
|
|
|
HID's got a bunch of problems in general. Apart from the aforementioned Boot Protocol keyboard and mouse protocols, there really is no such thing as a "keyboard" or "mouse" or "gamepad" or anything like that, it's all just HID devices. You have a bunch of inputs and outputs, they have raw data ranges and various codes that define their meanings (they're called "Usages" because it wouldn't be a Microsoft standard if it didn't use the most bizarre and incomprehensible terminology they could come up with). So you have like "Keyboard e and E" but you also have things like just, "Button 1" or "Axis X". Is it a mouse or a joystick? "Well like, what really IS a mouse anyway, maaan?". Controls can be bundled up into logical groupings and those logical groupings can have their own usage codes so if it's inside a "Generic Desktop Page" then that's the closest thing to a reliable indication that you are in fact dealing with a keyboard or mouse. This turns out to be a fairly major problem given that a keyboard is a device with the interesting characteristic that it is used to enter login credentials. So you don't want arbitrary applications to be able to read from those devices for obvious reasons, but if it's a gamepad then you don't care. As far as the Linux kernel is concerned though they're all just USB HIDs. Which is weird because it can comprehend HID report descriptors and decode HID packets just fine, it has a bunch of mechanisms for decoding USB usage codes into its own proprietary event packet codes after all. But for whatever reason it doesn't send a "this is something that Windows would consider to be a keyboard" device attribute to udev. So dealing with game controllers under Linux is more of a pain than it needs to be.
|
|
#
?
Jan 17, 2023 05:37
|
|
|
quote:Note gently caress you gently caress you gently caress you gently caress you gently caress you gently caress you gently caress you
|
|
#
?
Jan 17, 2023 05:47
|
|
|
Probably because Windows has concept of a "top-level collection", which is not something that explicitly exists in the HID standard, and Linux just has a concept of a HID device. A TLC is just a logical control grouping that isn't embedded inside some other logical control grouping. So you can have keyboards that have keyboard-y bits, which get exclusively locked by the Windows GUI subsystem, and then you can have some other TLCs that do other things which unprivileged applications can open and read from freely. But to Linux it's all one HID and access to it is an all-or-nothing affair. Best of all, HID devices are special compared to other USB devices, because under Windows you can access them relatively easily, you can just call SETUPAPI to list all of the HIDs in the system and then you look for your shitass device's VID/PID combination and open a file descriptor on it directly. Any other kind of device requires a kernel driver, which these days needs to be reviewed and counter-signed by Microsoft. Or you can use WinUSB for USB devices, but even then you have to write an INF file and then deal with WIndows' plug-and-play bullshit where your user will inevitably plug it in the hardware before installing its corresponding software and you'll get a confusing Unknown Device error. So yeah people often used USB HID to smuggle firmware updates because like hell anybody wants to deal with the bullshit of making a legitimate Windows device driver if they can avoid it. Just have a 64-byte "output" descriptor (the maximum size allowed for USB "interrupt" endpoints) and send 1000 of those per second (the maximum polling interval allowed for USB "interrupt" endpoints. Yes, "interrupt" endpoints are polled, shush) for a blistering transfer rate of 63 decimal kilobytes per second (the first byte must be a report ID, devices are allowed to define multiple report packet formats so they can use different packets to report changes on different sets of inputs/outputs). I guess technically USB HID also allows you to immediately force-poll reports via USB control messages instead of interrupt packets, but that probably isn't significantly quicker since control messages are usually used for things like device discovery and address assignment and are generally designed to be extensible instead of performant.
|
|
#
?
Jan 17, 2023 05:48
|
|
|
lol, is that really a common way of doing firmware updates? that sounds, uh, unreliable
|
|
#
?
Jan 17, 2023 06:13
|
|
|
I wrote a USB-based firmware updater that worked driverless on Windows, but I used the USB serial-port device class. Worked great. GadgetFS on the target device presented an ACM serial port. Worked with no special drivers on Windows 10 and 11.
|
|
#
?
Jan 17, 2023 06:58
|
|
|
that sounds like a more sane way of doing it tbh, i was thinking something along those lines would be better actually. i've never heard of anything using HID for it though but admittedly i don't really monitor that kind of poo poo anyway
|
|
#
?
Jan 17, 2023 07:03
|
|
|
post hole digger posted:wish you HID t hi s post 
|
|
#
?
Jan 17, 2023 07:39
|
|
|
Captain Pike posted:I really do wish this was possible. I wanna run GEM on linux. that’s why I said to run EmuTOS or FreeMiNT on Hatari it’s an emulator so run the emulator fullscreen on console from your .login and just live in the Atari Extended Universe, and pop over to an alt console any time you need to tweak anything Linux-side or use a (gross) browser hell I think Hatari even has MIDI support now, and someone made a USB stack for the ST that it supports too…
|
|
#
?
Jan 17, 2023 09:32
|
|
|
pseudorandom name posted:normal people don't spend their time thinking about racist slurs my dude “normal people” who post in the pos lol
|
|
#
?
Jan 23, 2023 12:19
|
|
|
im err a normal person
|
|
#
?
Jan 23, 2023 19:20
|
|
|
im a hosed up little freak
|
|
#
?
Jan 23, 2023 19:28
|
|
|
mycophobia posted:im a hosed up little freak What a loving loser. I’m a hosed up tall freak. 
|
|
#
?
Jan 23, 2023 19:38
|
|
|
I'm a freak because I finally made the jump to Linux in 2023
|
|
#
?
Feb 8, 2023 20:01
|
|
|
|
| # ? Apr 20, 2024 05:15 |
|
|
Seven Force posted:I'm a freak because I finally made the jump to Linux in 2023 well thank god your terminal can tell you if your screen resolution or widget toolkit changes Soricidus posted:“normal people” who post in the pos lol i have been playing around with GNUStep lmao
|
|
#
?
Feb 8, 2023 20:12
|
|