Fixes 'undefined reference' issue when hid-steelseries is built in,
but led-class is a module.
--
drivers/built-in.o: In function `steelseries_srws1_remove':
hid-steelseries.c:(.text+0x3b97a1): undefined reference to
`led_classdev_unregister'
drivers/built-in.o: In function
Fixes 'undefined reference' issue when hid-steelseries is built in,
but led-class is a module.
--
drivers/built-in.o: In function `steelseries_srws1_remove':
hid-steelseries.c:(.text+0x3b97a1): undefined reference to
`led_classdev_unregister'
drivers/built-in.o: In function
On Mon, 29 Apr 2013 20:46:47 -0400
Todd Showalter t...@electronjump.com wrote:
On Mon, Apr 29, 2013 at 5:04 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
I'm a game developer, and I'm interested in discussing changes in
the way gamepad input is handled at the evdev and device
Hi Dmitry
Any update on this?
Regards
David
On Thu, Mar 28, 2013 at 12:59 PM, David Herrmann dh.herrm...@gmail.com wrote:
If userspace requests current KEY-state, they very likely assume that no
such events are pending in the output queue of the evdev device.
Otherwise, they will parse
On Thu, May 2, 2013 at 2:35 AM, Antonio Ospite osp...@studenti.unina.it wrote:
On Mon, 29 Apr 2013 20:46:47 -0400
Todd Showalter t...@electronjump.com wrote:
My proposed standard gamepad is:
- left stick (2d vector, each component [-1.0f .. 1.0f])
- right stick (2d vector, each
Hi Todd
On Thu, May 2, 2013 at 3:46 PM, Todd Showalter t...@electronjump.com wrote:
On Thu, May 2, 2013 at 2:35 AM, Antonio Ospite osp...@studenti.unina.it
wrote:
On Mon, 29 Apr 2013 20:46:47 -0400
Todd Showalter t...@electronjump.com wrote:
My proposed standard gamepad is:
- left
On Thu, May 2, 2013 at 10:09 AM, David Herrmann dh.herrm...@gmail.com wrote:
What do you do with devices that don't provide these buttons? (like
the Wii Remote) What do you do with HID devices which include the
mapping in their HID-descriptor (you need fixup HID-descriptors for
each and every
Webmail makes it too easy to fat-finger send.
On Thu, May 2, 2013 at 10:09 AM, David Herrmann dh.herrm...@gmail.com wrote:
So if you want reliable gamepads, the easiest way is a user-space
mapping based on device-names. This guarantees you get the expected
buttons. Adding support for new
On Thu, May 02, 2013 at 11:37:48AM -0400, Todd Showalter wrote:
Ok, here's a question: could gamepad-like devices have two dev
entries? One that exported the full raw device, and one that
responded to EVIOCGNAME with Standard Gamepad? That way, the raw
device in all its glory would be
On Thu, May 02, 2013 at 09:46:44AM -0400, Todd Showalter wrote:
left stick: ABS_X, ABS_Y
right stick: ABS_RX, ABS_RY
Not sure about this one. Originally RX, RY and RZ were introduces for
device having more than 3 degress of freedom; and RX is used by many
joystick devices. We'd ether need a
On Thu, May 2, 2013 at 12:38 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
I wish we have gotten all the mappings correct from the get go, but that
did not happen, so now we need to move forward. That means that we can
establish the canonical mapping and try to follow it for the new
On Thu, May 2, 2013 at 1:01 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
On Thu, May 02, 2013 at 09:46:44AM -0400, Todd Showalter wrote:
left stick: ABS_X, ABS_Y
right stick: ABS_RX, ABS_RY
Not sure about this one. Originally RX, RY and RZ were introduces for
device having more than
Hi Todd
On Thu, May 2, 2013 at 7:35 PM, Todd Showalter t...@electronjump.com wrote:
On Thu, May 2, 2013 at 1:01 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
On Thu, May 02, 2013 at 09:46:44AM -0400, Todd Showalter wrote:
left stick: ABS_X, ABS_Y
right stick: ABS_RX, ABS_RY
Not
On Thu, May 02, 2013 at 01:06:59PM -0400, Todd Showalter wrote:
On Thu, May 2, 2013 at 12:38 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
I wish we have gotten all the mappings correct from the get go, but that
did not happen, so now we need to move forward. That means that we can
On Thu, May 2, 2013 at 1:54 PM, David Herrmann dh.herrm...@gmail.com wrote:
How about a new input property that marks devices that follow general
rules as such? So for instance:
INPUT_PROP_DEV_MOUSE
INPUT_PROP_DEV_KEYBOARD
INPUT_PROP_DEV_GAMEPAD
INPUT_PROP_DEV_JOYSTICK
And so on.
On Thu, May 2, 2013 at 2:29 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
- any mapping library is going to have to be a mirror of the kernel
code, which means it's basically just a lot of duplicated effort with
the added penalty of update lag
The library can do much more than that.
On Thu, May 02, 2013 at 03:54:45PM -0400, Todd Showalter wrote:
On Thu, May 2, 2013 at 2:29 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
- any mapping library is going to have to be a mirror of the kernel
code, which means it's basically just a lot of duplicated effort with
the
On Thu, May 2, 2013 at 4:18 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
No, I do not think so. Kernel provides a level of abstraction, but so
does X, ALSA, given desktop environment and so forth. If a task does not
require hardware access (and translating input events form one type to
On Thu, May 02, 2013 at 03:10:55PM -0400, Todd Showalter wrote:
On Thu, May 2, 2013 at 1:54 PM, David Herrmann dh.herrm...@gmail.com wrote:
How about a new input property that marks devices that follow general
rules as such? So for instance:
INPUT_PROP_DEV_MOUSE
On Thursday, May 02, 2013 04:30:01 PM Todd Showalter wrote:
On Thu, May 2, 2013 at 4:18 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
No, I do not think so. Kernel provides a level of abstraction, but so
does X, ALSA, given desktop environment and so forth. If a task does not
On Thu, May 2, 2013 at 4:45 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
I'd far rather the games with special needs had to do heavy
lifting than have the common case be complicated just because someone
might want to use a wiimote with a balance board plugged in though a
motion
On 05/01/13 23:27, Simon Wood wrote:
Fixes 'undefined reference' issue when hid-steelseries is built in,
but led-class is a module.
--
drivers/built-in.o: In function `steelseries_srws1_remove':
hid-steelseries.c:(.text+0x3b97a1): undefined reference to
`led_classdev_unregister'
On Thu, 2 May 2013, Randy Dunlap wrote:
---
drivers/hid/hid-steelseries.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-steelseries.c b/drivers/hid/hid-steelseries.c
index 2ed995c..dbd5e2e 100644
--- a/drivers/hid/hid-steelseries.c
Fixes 'undefined reference' issue when hid-steelseries is built in,
but led-class is a module.
--
drivers/built-in.o: In function `steelseries_srws1_remove':
hid-steelseries.c:(.text+0x3b97a1): undefined reference to
`led_classdev_unregister'
drivers/built-in.o: In function
24 matches
Mail list logo
