On Mon, Jan 10, 2011 at 5:12 PM, Peter Hutterer <[email protected]> wrote: > On Mon, Jan 10, 2011 at 11:34:55AM -0800, Ping Cheng wrote: >> On Mon, Jan 10, 2011 at 3:10 AM, Cedric Sodhi <[email protected]> wrote: >> > On Mon, Jan 10, 2011 at 09:16:14AM +1000, Peter Hutterer wrote: >> >> On Sat, Jan 08, 2011 at 11:51:41AM +0100, Cedric Sodhi wrote: >> >> > I'm curious whether it would be possible and make sense to implement the >> >> > mode in which the pen could be read out so that it's proximity value >> >> > (which is currently in no way getting anywhere beyond the driver) is >> >> > mapped to pressure (and pressure doesnt matter). >> >> > >> >> > One of the buttons could enable "spraying" and the position with the >> >> > tilt could be calculated to an intercept with the physical pad: >> >> > _ >> >> > \\ >> >> > \\ >> >> > \\ >> >> > |¯\ >> >> > \½\ >> >> > \ \ _ >> >> > ¯¯ |-- Proximity >> >> > ‚———————×———————‚ ¯ >> >> > ^-- Intercept (calculated from tilt and position) >> >> > >> >> > I think it would be very interesting to use the stylus as a natural >> >> > airbrush, if that could be done. >> >> > >> >> > Maybe an evaluation from one of the professionals (Ping, Peter?) whether >> >> > this would be possible at all? If the answer is yes, someone else might >> >> > start looking at how in particular this could be done if you guys are >> >> > busy with something else. >> >> > >> >> > Would make a good feature over the windows driver, no? ;) >> >> >> >> should be trivial to export distance through another axis. I'm not keen on >> >> mapping it to pressure at all though, easier to add another axis and >> >> handle >> >> them separately. >> >> >> >> Cheers, >> >> Peter >> > >> > Hello Peter, >> > >> > at first, I'm not even sure that the distance between the pad and the >> > tip is exported as a usable value any more. The driver says something >> > about CursorProx distance and mentions a default of 10 for the Intuos4, >> > but upon further investigating that property the driver than claims that >> > such a property does exist of none of the devices. >> > >> > Is such a value even exported by the pad? I'm not really sure anymore. >> > >> > If it happens to be provided, why would you provide it on a separate >> > channel? To be frank, I wouldn't see any advantage in using it without >> > the according calculation of an intercept and providing latter in the >> > primary two channels. >> > >> > I'm assuming a GTK like interface to XInput (as provided by GIMP) where >> > you can map specific channels of one input device to specific funtios in >> > the program. If the mode is switched to "airbrush" that data must then >> > either be provided on a different XInput device (e.g. "Wacom Intuos4 6x9 >> > airbrush") or must remain mapped to pressure, so one doesnt have to >> > change the meaning of channels. >> > >> > But as I said, I start questioning whether that value exists, at all. >> >> Yes, distance is supported for Intuos and Bamboo series. Right now, it >> is only used for Wacom mouse (cursor in Wacom driver's term) since the >> tool is in relative mode. Distance is enabled to force the tool out of >> prox so users don't have to lift the puck/mouse too high to reset the >> movement. >> >> Distance can definitely be used to support other features. But, I >> agree with Peter. We do not want to mix distance with pressure. Those >> two should be reported in separate axis to the clients. If we want to >> add features in the driver, it should be configurable through >> xsetwacom command. Users, even application like Gimp, can turn the >> feature on/off when needed/supported. > > note that there isn't just a single client that needs this information, so > we can't just let GIMP decide which axes the driver reports.
No, I was not talking about sending the distance value for the sake of one application. I took Gimp as an example to show that end users or an application can turn the specific features on or off by xsetwacom. Those features are the ones that we may add to xf86-input-wacom to use distance values specifically. But they are not application specific interfaces. > if may break another application also relying on XI for exactly those values. The raw distance value should be reported in a fixed axis. I have no question about that. In fact, I emphasized this concept with the following comments: "I agree with Peter. We do not want to mix distance with pressure. Those two should be reported in separate axis to the clients." Ping ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
