From: Magnus <wi...@bi...> - 2006-11-24 22:23:18
|
Actually you managed to make me a bit confused.. :-/ As I see it there are two drivers; the kernel module and the X-driver. I ho= pe=20 I didn't write in a way that indicated that I wanted to make changes to the= =20 kernel module. Because I don't think the changes we're talking about really= =20 fits there... The reason I'm a little confused is that I'm not sure which driver you writ= e=20 about below after the three InputDevice sections. If I read it correctly I= =20 would say it would be both. I'll make a more thoroughly commented reply, but I'd like to know I didn't= =20 misunderstand what you've written first. BR Magnus On Friday 24 November 2006 22:24, Ping@LinuxWacom wrote: > On 11/23/06, Magnus Vigerl=F6f <wi...@bi...> wrote: > > I've had a few thought and an idea to deal with a few of the tracker > > items, > > specifically these: > > > > [ 676326 ] Support for a tablet menu > > [ 1519017 ] unable to define different areas for one stylus > > [ 1559640 ] Screen mapping > > > > If I should start somewhere I think [ 1519017 ] would be the one I'd > > implement > > first, but I have an idea of how to do it that would enable us to do the > > other ones with relatively little effort. > > Great. I'd like to see 1519017 resolved first too. > > If I understand it correctly the driver looks at the Tool > > > (stylus/eraser/pad/...) and also the serial id of it if one's defined a= nd > > supported by the tablet. Anything else is not considered when choosing > > the InputDevice from the x-config. So adding TopX/Y, BottomX/Y > > limitations will > > only leave you with one area for each specific tool. The simple way to > > solve > > this, would be to add the area as another filter of which you can use to > > select the right InputDevice. > > > > This would mean that you would need to define the same areas for all > > Tools that should act the same when used on the tablet, which would > > inevitable lead > > to multiple definitions of the same areas in our x-config. Bad thing? N= ot > > really, but why define something twice if you can avoid it? > > The tool is mainly distinguished by its type and identifier in xorg.conf. > Serial number can be used to differentiate tools of the same type only if > the tablet model supports tool serial number, which includes Intuos 1, 2,= & > 3 series and Cintiq 21UX so far. > > So the challenge to 1519017 is to define more than one tablet to > screen mapping for the same tool type. The only character to distinguish > them is their identifiers. Following is an example of one tool (without > serial number) maps 3 areas. I'll briefly explain the idea behind this > definition. Assuming it is under a dual-monitor display setup, we want to > access only one screen or the whole desktop depend the area on the tablet > that the stylus is moving. stylus0 maps up-left of the tablet onto screen > 1. stylus1 maps the up-right of the tablet onto screen 2. stylus2 maps the > lower 1/3 of the tablet onto the whole desktop. > > Section "InputDevice" > Driver "wacom" > Identifier "stylus0" > Option "Device" "/dev/input/wacom" > Option "Type" "stylus" > Option "USB" "on" > Option "ScreenNo" "0" > Option "BottomX" "1250" #assuing 1250 is the half of the > tablet's width > Option "BottomY "956" # 2/3 of tablet heighth > EndSection > > Section "InputDevice" > Driver "wacom" > Identifier "stylus1" > Option "Device" "/dev/input/wacom" > Option "Type" "stylus" > Option "USB" "on" > Option "ScreenNo" "1" > Option "TopX" "1251" > Option "BottomY" "956" #TopY and BottomX are default values. > No need to define. > EndSection > > Section "InputDevice" > Driver "wacom" > Identifier "stylus2" > Option "Device" "/dev/input/wacom" > Option "Type" "stylus" > Option "USB" "on" > Option "TopY" "957" #TopX, BottomX ,and BottomY are > default values. No need to define them again > EndSection > > > So, in your implementation, you need first validate the mapping areas. Th= at > is, you need to make sure the areas that defined for the same tool (same > type, and same serial number if used, but different identifier) don't > overlap since there is no way for you to send stylus1 or stylus2 event > unless you know which area the tool is in. For overlapped definition, log > the error and ignore the tool. > > Then, in the X driver, you need to switch tools whenever an area change > happens. In this case, the mapping area is a key factor to distinguish the > tools except their identifier, which is defined in xorg.conf. > > Let me know if you get lost. > > > Next request, [676326]. If the above is in place we could define areas for > > > buttons, lots of them. We only need to translate the different ways of > > simulating different button presses depending on if you tap the stylus, > > press > > a button on it, etc.. No big deal with the translation I think. > > > > One catch I can see with this however would be that each of the defined > > buttons will get it's own InputDevice, maybe it would be possible to se= nd > > them all to a faked pad InputDevice. But I'm really not keen on doing > > that as > > my view of the InputDevice is something that actually generate some kind > > of > > data and not a dummy-device. > > Tablet menu area should be defined inside the driver without configuration > interference due to its complexity and the different size for different > tablet. The functions that associated with each menu button could be > configured later in xorg.conf. But definitely not the menu area. For > different tablet, a different number of menu buttons should be supported. > This can be understood by the width of the tablet. It is unrealistic to > support the same number of menu buttons for smaller tablet as for those b= ig > 12x12. The goal here is to make it simple and easy to use for end users. > Not every Linux users are as savvy as we are :). So, if we use my > approach, there is no need to introduce new xorg.conf options. Let me kn= ow > if this is unreasonable to you. > > Another catch would be how to handle multiple Tools. For each Tool that > > > should > > support the buttons, they all had to be defined for it. That would then > > lead > > to even more InputDevices. Maybe the tools with different serial ids can > > get > > away in this case, but I'm not sure they would. > > I think we can defer this support for now. My idea is: we make features > as simple as we can first. Let the community use them for a while to gath= er > feedbacks. Feature enhancement will be considered as we upgrade the simp= le > ones. > > For me having the same definitions on the buttons for all tools would be > the > > > sanest. I can't see changing them depending on the used Tool would be > > useful, > > except for the touch-screens where I think having real UI-buttons would > > be better and more understandable anyway. So I think this way would > > create an unnecessary amount of area definitions and InputDevices, some > > of them doing > > the exact same thing. > > I Agree. |