dale@jack.ci.com (Dale Gallaher) (03/17/91)
Has anyone implemented applications which use tablet input instead of the mouse. We have a CAD package where many uses prefer using a tablet but I have never seen anyone discuss using tablets in X. Maybe it has been discussed and I just missed it. -- Dale Gallaher Cognition Corp. dale@dandelion.ci.com (508)667-7900 x121 Billerica, MA
rthomson@mesa.dsd.es.com (Rich Thomson) (03/19/91)
In article <1165@dandelion.CI.COM> dale@jack.ci.com (Dale Gallaher) writes: > Has anyone implemented applications which use tablet input instead > of the mouse. We have a CAD package where many uses prefer using > a tablet but I have never seen anyone discuss using tablets in X. The X input extension allows input from a wide variety of devices. However, the support for the input extension must be built into the server (including driving the devices). It is not plug-and-play in that respect. Also, applications that wish to use these devices must call the client-side routines that interface to them. An interesting thing is that you can change the core pointer to be a tablet instead of the mouse. If you do this, applications that are mouse-based could use a tablet without having to know they were using the tablet. You can change back and forth without restarting the server (or any client, for that matter). E&S has been using the input extension in its X implementation to provide: tablets (several varieties of different sizes), dial boxes (8 dials with 8-character LED labels), and a button box. I am not aware of which other vendors are using the X input extension, but the extension was contributed by HP. -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
marbru@attc.UUCP (Martin Brunecky) (03/19/91)
In article <1991Mar18.170530.13580@dsd.es.com> rthomson@dsd.es.com (Rich Thomson) writes: >In article <1165@dandelion.CI.COM> > dale@jack.ci.com (Dale Gallaher) writes: >> Has anyone implemented applications which use tablet input instead >> of the mouse. We have a CAD package where many uses prefer using >> a tablet but I have never seen anyone discuss using tablets in X. > >The X input extension allows input from a wide variety of devices. >However, the support for the input extension must be built into the >server (including driving the devices). It is not plug-and-play in >that respect. > We have taken a slightly different approach. Since we want to treate the digitizer suface similarly to the screen, i.e. lay windows on the top of it, get enter/leave/button/motion events etc., we decided to strip-down (lobotomize) the MIT X Server. So our application, which can use up to 4 different digitizer widgets, opens an additional display connection: to a digitizer server. It can create widgets (such as plain digitizing areas with various pointer tracking modes, menu, screen-pointer-mapper etc.) using all the Xt functionality. The only specific is that windows can be rotated, not only parallel to x,y axis. The server is a "lobotomized" MIT X server. It has all the graphics output stubbed out (XDrawLine - sure, success - don't you see your line?), all the fonting stuff stubbed out, all the colormap stuff stubbed out. It still deserves some work ... but it does work. The server is much smaller then the "real" one, does not eat almost any CPU. And you can even use a digitizer connected to other machine ! There are still some issues to work out: How do the 2 applications share the digitizer without a window (digitizer) manager ? What you do with a digitizer resolution 100,000 x 100,000 dots when the Xt defines "Position" as "short" ..... -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
dale@dandelion.ci.com (Dale Gallaher) (03/21/91)
In article <1276@attc.UUCP>, marbru@attc.UUCP (Martin Brunecky) writes: |> In article <1991Mar18.170530.13580@dsd.es.com> rthomson@dsd.es.com (Rich Thomson) writes: |> >The X input extension allows input from a wide variety of devices. |> >However, the support for the input extension must be built into the |> >server (including driving the devices). It is not plug-and-play in |> >that respect. |> > |> |> We have taken a slightly different approach. Since we want to treate |> the digitizer suface similarly to the screen, i.e. lay windows on the |> top of it, get enter/leave/button/motion events etc., we decided |> to strip-down (lobotomize) the MIT X Server. |> Since both of these aproaches involve specialized servers they are not really helpful for us. We have users of our CAD package that used to use it in sunview and we included support for a tablet. Now most of the users are converting to OpenWindows, but we have not included and support for the tablet. The reason I brought this up with moving the pointer was I thought maybe it could be done by just listening to the tablet and warping the pointer to follow. The pointer would also follow the mouse if the mouse position changed. Essentially it would follow which ever was moved last. If the pointer left our application then we would ignore the anything from the tablet until the pointer came back to our application. Does this sound reasonable or too much of a hack to be practical? Otherwise, it seems our tablet uses our stuck with Sunview, and I am not sure how much longer Sunview will be around. -- Dale Gallaher Cognition Corp. dale@dandelion.ci.com (508)667-7900 x121 Billerica, MA
newsuser@oliver.SUBLINK.ORG (Ugo Cei) (03/22/91)
marbru@attc.UUCP (Martin Brunecky) writes: >In article <1991Mar18.170530.13580@dsd.es.com> rthomson@dsd.es.com (Rich Thomson) writes: >>In article <1165@dandelion.CI.COM> >> dale@jack.ci.com (Dale Gallaher) writes: >>> Has anyone implemented applications which use tablet input instead >>> of the mouse. We have a CAD package where many uses prefer using >>> a tablet but I have never seen anyone discuss using tablets in X. >> >>The X input extension allows input from a wide variety of devices. >>However, the support for the input extension must be built into the >>server (including driving the devices). It is not plug-and-play in >>that respect. >> > We have taken a slightly different approach. Since we want to treate > the digitizer suface similarly to the screen, i.e. lay windows on the > top of it, get enter/leave/button/motion events etc., we decided > to strip-down (lobotomize) the MIT X Server. You could also use a much more simple-minded approach: warp the pointer when the stylus or the mouse on the digitizer moves. You could create a program which reads the stylus position and outputs a couple of coordinates whenever the position changes. Your application has to open a connection to this program (e.g. using popen) and make the server listen to it (via XtAddInput). I've tried this and it worked, even though movement of the pointer either lagged behind the actual movement of the stylus (too many coordinates being input) or the movement wasn't smooth enough when I tried to output them less frequently. Eventually, I obtained satisfying performance by disposing entirely of XtAddInput and warping the pointer from the program connected to the digitizer, like this: while(forever) { read coordinates from digitizer if(they have changed) warp pointer to the new location } You also need to generate fake ButtonPress/Release events (via XSendEvent) when the user presses/releases the stylus or mouse button(s). If you send these events to the root window instead of your application's main window, you can control the entire X session using the digitizer, but beware that many applications require a three button mouse to work properly and even some key+button combinations. Also, when you stop moving the digitizer, you regain control of the pointer through the mouse. -- **************** | Ugo Cei | SUBLINK: newsuser@oliver.sublink.org * OLIVER * | Via Colombo 7 | INTERNET: cei@ipvvis.unipv.it **************** | 27100 Pavia ITALY | "Real Programs Dump Core"
rthomson@mesa.dsd.es.com (Rich Thomson) (03/25/91)
[I massaged your message to sanely fit into 80-character lines -- let me guess, you read news with xrn? What a losing program...] In article <1167@dandelion.CI.COM> dale@dandelion.ci.com (Dale Gallaher) writes: > Since both of these aproaches involve specialized servers they are > not really helpful for us. [...] > The reason I brought this up with moving the pointer was I thought > maybe it could be done by just listening to the tablet and warping > the pointer to follow. Well, unless your tablet produces the same serial byte stream as your mouse you're going to require a server with support compiled in for the byte stream of the tablet. If your tablet and your mouse are byte-stream compatible, then just swap the plugs ;-}. Short of that, there's no way you're going to get tablet support without modifying the application. (Your application could always monitor the tablet I/O port and interpret the data stream). Alternatively, you could develop a listener program that sat in the background and monitored the tablet I/O stream. This program could then synthesize mouse events that are equivalent to the tablet motion. This approach might let you get by without modifying your server or your application, but it is not the most integrated of approaches. Computer Science: whatever works -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
marbru@attc.UUCP (Martin Brunecky) (03/26/91)
In article <919@oliver.SUBLINK.ORG> newsuser@oliver.SUBLINK.ORG (Ugo Cei) writes: >You could also use a much more simple-minded approach: warp the >pointer when the stylus or the mouse on the digitizer moves. You could >create a program which reads the stylus position and outputs a couple >of coordinates whenever the position changes. Your application has to >open a connection to this program (e.g. using popen) and make the >server listen to it (via XtAddInput). Using XtAddInput to "make server listen to it" ??? I would more think of an independent program, communicating between the tablet and the server, running independently of the application. A simple tablet data collecting loop, generating XWarpPointer on a server connection. This would certainly do if the goal is only to move the pointer around, without any other application activity on the tablet (such as digitizing, menus, signature recognition ...). > >You also need to generate fake ButtonPress/Release events (via >XSendEvent) when the user presses/releases the stylus or mouse >button(s). If you send these events to the root window instead of your >application's main window, you can control the entire X session using >the digitizer, but beware that many applications require a three >button mouse to work properly and even some key+button combinations. >Also, when you stop moving the digitizer, you regain control of the >pointer through the mouse. Mhmmm. I have some experience in this field ... First of all, sending events to the root window did not work for me. I had to find the topmost window above the pointer interested in the button event (even propagate was giving me a headache), to deliver my sent-event to the proper window and application. (Not many applications request button events on the root window of the screen). Next, the real problem are grabs. On the true button down event, the server grabs the pointer (and releases it on button up). So far, I haven't found a way to simulate this one - not even talking about the fact that while the simulated button down is "active", the user can press the real button and confuse things even more. To summ it up, I have found that for many simple uses the "fake" button events do work. But not always. For example, window managers often do some magic on button downs (such as grabbing the server) - so performing (many of) WM functions through "fake" button events from the tablet simply does not work. I suspect that the "real" solution here is to use something like XTest extension - but it again falls into the pitthole of which server supports which extension .... -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404