P? Sun, 23 Oct 2005 14:35:27 +0200, skrev Ryan C. Gordon
:
I need to look at that again. I think I was generally nervous about
adding more-than-generic mouse functionality, but multiple inputs aside,
it’s come to my attention that working with evdev/XInput/WM_INPUT/HID
Manager directly really sucks, so ManyMouse might be a nice API in place
of that even for things like pens. Ideally the app can just ignore
tablet-specific events and treat the thing like a mouse if it wants to.
I have to look at your patch again, it might already do this.
Well, my patch was pretty simple – it only added activation notification
for tablet-like tools (including absolute mice) so that an absolute-to-
relative converter can detect this event and reset its "last seen at"
values so that absolute-to-relative conversion can actually work. This
was originally only intended to improve the support for absolute mice
that ManyMouse already has, but since there was an unused field in the
activation event, and tool id information has to be accessed anyway to
get the activation info, I put the tool id in the extra field to specify
what tool entered or left the active area. The activation event and its
fields can be safely ignored by an application (it just won’t be able to
do absolute-to-relative conversion properly). I didn’t add any other
tablet-specific events in the patch I sent you, but it wouldn’t be hard
to do (for evdev at least).
Anyway, in my opinion ManyMouse would be very nice as (or as a base of)
an input library supporting tablets – when you’re working with tablets
you typically want to support multiple devices anyway. The tablet is
rarely the primary input device, and you often switch between the tablet
and other input-devices while working with it (well, at least I do that).
However (and this could be an SDL issue at some point), the latest x.org
grabs the evdev devices for exclusive access…mostly because if they
don’t, your keystrokes fall through to the the Linux VT which also use
evdev for the keyboard, and you could have accidentally CTRL-C’d your X
server when you meant to CTRL-C something in an xterm on that X server.
Is it an option, or are you actually forced into having Xorg grab evdev ?
This means we’ll pretty much have to move to XInput for this to be
useful, but on x.org, XInput is either broken or misconfigured on every
system. It’s a hard problem.
One mouse should work fine, right ? So, we only have to worry about
multiple mice and possibly tablets at once ?
I use Xorg, and my tablet works perfectly in the GIMP, with pressure
and tilt sensitivity, tool ids, and all buttons on the tools doing
what they should. GIMP doesn’t sense the tablet unless it’s set up in
xorg.conf, which means it’s using XInput, right ? (Or am I wrong ?)
I didn’t have to do any magic to get this working, just installed the
driver from the linux-wacom project and followed its instructions for
setting up X. Okay, so I had to hunt down and install a driver, but
other than that it was actually a pretty straighforward process.
Now, the question is if getting multiple regular mice to work would
be as easy. My guess is “no”, since you say it’s a hard problem,
but if it’s possible to get a tablet working, multiple mice should
be possible as well … If not, has anyone reported this as a bug to
the Xorg people ?
