Touchscreen Driver

I am just writing a touchscreen driver for my D-WAV eGalax 8’ Monitor.

It is nearly finished. I want to allocate a mouse driver number for it. How can I do so? !Allocate doesn’t provide such a point.

Therew is also the question how to simulate the mouse clicks. In the moment I am waiting a couple of centi seconds to switch between the emulated buttons. I am quite satisfied with this method in the moment. I know that there have been or still are touch pads for RISC OS but I am not owning one so I don’t know how they are simulating clicks. I don’t want to implement a different handling.

Can anyone tell me whether there is a standard for RISC OS to simulate button clicks?

Regards

Thomas Milius

Pace ported RISC OS to a number of devices with touch screens. As far as I recall, the technique used was for short touches to be interpreted as Select, and slightly longer touches as Menu. For Adjust, I think we required a keyboard key to be held down at the same time. It helps that RISC OS doesn’t use drags with the Menu button, so there’s no confusion between Select drags and Menu drags.

You’ll certainly find *Configure WimpClickSubmenus useful, since with a touchscreen there’s no way you can hover over a submenu arrow in order to open the submenu.

Dunno about patent status, but provided the touch screen hardware can report the relevant information and the driver is capable of picking it up, you could copy MacOS X and use a double finger tap to act as one button. Indeed, using multiple fingers works well – one for Select, two for Menu, three for Adjust. Dragging with multiple fingers can be useful too (e.g. two fingers for scroll wheel action).

It is nearly finished. I want to allocate a mouse driver number for it. How can I do so? !Allocate doesn’t provide such a point.

Use the “Devices” part of !Allocate to generate your request and I’ll allocate you a pointer device number. You’ll need to give your device a name (“MicrosoftMouse” is an exampe) and a description (“Touch screen pointer device” or the like).

My touchscreen driver allows Select, Menu and Adjust clicks (and double clicks) as well as dragging, so you can navigate menus and even Adjust-click on menus and keep them open for more selections.

I can’t remember how I did the mouse clicks at the moment and the code isn’t here.

It only works on MicroTouch (3M) serial screens at the moment though.

During the last week I tested my driver intensively and kicked out bug by bug. However in the moment there is a problem left with certain applications (especally !Draw) that crashes the application if I perfoming long SELECT movings.

The scheme for button is in the moment that the touch during the first time simply behaves like a normal moving. Then it switches to SELECT, MENU, ADJUST and back to normal pointer bahviour again. If releasing the pen during the SELECT, MENU, ADJUST phase a button click/realese is sent to Keyboard and this kind of button emulation is taken for a certain time (Doubleclick interval) in cases that the pens touches again. If movings are performed a click is sent at the first position where the pen touched and afterwards a movement to the actual position. I find the this concept meanwhile quite useable. For it makes full usage of the regular mouse driver I can do everything I can also do with the mouse. The concetp seems to be very similar to Paces handling concept but does not require the keyboard.

To indicate the actual state the mouse pointer (shape 1) changes through the selection phase. However this doesn’t works for !Draw. But I can draw simply lines with it only relying on the time interval.

I made one really stupid bug as I forgot to set C-Modulcode generation flag. Afterwards I forgot to save the FPE Context. The driver contains a distortion compensation which makes heavy usage of double-operations. I hope that I sorted this out well meanwhile by calling the according FPE-ChangeContext SWI (from C).

Now I am worrying about remaing click moving bug. Perhaps I have to Claim KeyV to synchronize my button state with the keyboard driver. But I shall see.

If the last last bug has been sorted out I shall claim terms and numbers as Steve told me above. I hope to kick out the last bug soon.

I have sorted out the bug now. I had to replace the floating point operations by integer ones.

I have have requested some allocations and hope to publish driver and source soon.

So, this has been available for a while. I was just wondering if there are any recent comments to add. And Thomas, have you found (aspects of) RISC OS to be usable with the monitor, thanks to your work on the driver? Also, does anyone know whether it’s possible that the Pace drivers could also become available some time? And what about the touchscreen on the Omega?

I must say that my monitor is a really small one. It has only an 8 ’ display. I am using it either if I am on RISC OS meetings in Germany or if playing around with my OBD interface in my car for it is so small.

So there is not really much experience. It is definitely useable. A problem for me is that the monitor is a light weight and I am not fixing it. So if I am touching too much there is the danger that it might fell and if I am touching only a bit some touchs are not detected.

However during our RISC OS meetings I used the filer/Photodesk/Artworks/Draw/Zap/Inetrnet Browsers and some other programs with it. I didn’t try a game. It is definitely not so fast and comfortable as using a trackball or mouse but I am finding it more useable like Windows based Laptop slide areas (ok perhaps too big fingers …).

For 8 or 10 ’ monitors a touchscreen is ok. But it is really nothing to do CAD/vector drawing or painting. In such cases digitzer tablets are definitely the much better choice.

There is always the question how to emulate mouse clicks. I think the concept I am using inside my driver is useable but there might be better ones. In general the absense of a real buttons is always a heavy burden if doing real work. However for small tasks like usually done on tablet computer it would work.

In general the absense of a real buttons is always a heavy burden if doing real work. However for small tasks like usually done on tablet computer it would work.

Indeed. But for things like making selections in dialogue boxes, dragging files around and navigating websites, I think it’ll be potentially quicker via a touchscreen. (This is what I’m finding on the Touch Book under AIOS, even without using the stylus.) I’m sure the TB touchscreen driver is in their sources, but I just found this reference to tslib on OMAP, which may also be of some interest. (Or… more likely… turn out to be a red herring!)

For the Touch Book, the AU Optronics B089AW01 V0 screen uses this ADS7846 based driver. Thomas, is this any use? While unfortunately I wouldn’t know how to integrate this into a module from scratch, I should be able to build something and test changes if you’re able to advise how.

I just had a thought about the mouse clicks. It is based on a tab and a swipe. The tab indicates the position and the swipe the action. From the tab you can swipe your finger in 8 directions (up, right, down, left, up-right, down-right, down-left and up-left). This gives us 8 possible click combinations, like:
tab + swipe left = select single click
tab + swipe left-up = start select drag
tab + swipe left-down = select double click
tab + down = menu click
tab + swipe right = adjust single click
tab + swipe right-up = start adjust drag
tab + swipe right-down = adjust double click

This leaves tab + up free for something else.

After the tab + swipe has been recognised a pointer change will inform the user of this. This is necessary for drags, eg: If you want to scroll down you first tab the vertical scrollbar and swipe left-up. After the pointer change you can then swipe down to really scrolldown. This involves an extra movement but I think once you used to it it will become second nature.

The suggested left/down/right for select/menu/adjust seems logical. But it might prove to be simpler to use IMHO if the UI for touchscreen use were to be simplified, perhaps with short/long touches. Adjust-dragging in the filer could possibly be dealt with by a pop-up window, or a more complicated addition along the lines of nemo’s hover work, e.g. visual indication of adjust drag (replacing with a different dragged icon or pointer shape) effected by scribing a small circle or something before releasing the touch.¹

Selecting items (in the filer or elsewhere) using Adjust would be another matter (in which case, the right-swipe could be easier). If a long touch is normally Menu, then a long touch away from the selected item could be interpreted as Adjust…² but then that item would be in the selection set and the user would want a long touch to be Menu again (to perform an action) but may also want to Adjust-click again to deselect the item. Hmmm… any ideas?

As an alternative to left/down/right swiping for buttons there’s multitouch, with swiping for other features.

In any case, it’d be good to be able to try out different implementations some time.³ There are currently more ARM touchscreen tablets around than netbooks!

¹ There’s probably a better solution already out there… But if not, this would presumably mean storing previous pointer positions and calculating whether the user is trying to scribe a shape. Clockwise to switch to Adjust-click, anti-clockwise to revert to Select-click?

² Adjust-selecting with long touches would be painfully slow for multiple items. In this case, an option to default to Adjust clicking may be helpful for touchscreen use.

³ Coding and tweaking an optimum touchscreen implementation sounds like a mammoth task, and isn’t a todo item. But discussion here could still be informative for some point in the future.

Any Idea what has happened to this?

From Steve Revill’s post:

Touch screen driver now in cvs

https://www.riscosopen.org/forum/forums/1/topics/136

https://www.riscosopen.org/viewer/view/bsd/RiscOS/Sources/ThirdParty/TMilius/HWSupport/Input/TchScrn/