I've recently bought myself a Windows Tablet PC with a touchscreen thinking my Allegro project would just work with it. Turns out I was wrong
Since I invested a lot of money in the tablet, I was determined to get Allegro working with it. The good news is that I managed to finally get everything working (stylus/mouse/touch.) The bad news is I'm not sure the best way to implement this directly into Allegro.
Some specs:
Toshiba Portege M750 with touchscreen
Windows Vista Business
Allegro 4.2.2
First I searched these forums and found no solutions. A search for "tablet" brings up a bunch of posts on Wacom tablets. And searching for "touch screen" brings up a few posts which describe my problem, but their solutions seem to work for Wacom tablets, not touch screens or styluses (styli?) I tried commenting out the handlers for DIMOFS_X and DIMOFS_Y in wmmouse.c, function mouse_dinput_handle_event. No luck, just broke everything.
The behavior I see is the cursor is always at one corner of the screen. But I found if I point the stylus at the center and move just a little, then it will bounce around dramatically, but still be somewhere on the screen.
I checked out what data is being returned from Direct Input. It looks like data being passed to mouse_dinput_handle_event are in range (-2560, -1600) - (2560, 1600) Absolute coordinates. But if you use the mouse then relative coordinates are passed. Touch screen is also absolute, but I did not check to see the range. Since the behavior is similar to the stylus input, my guess is that it's the same.
PROBLEM 1: How does someone tell if the data being passed is relative or absolute?
PROBLEM 2: How do I know what device is sending me the data?
PROBLEM 3: How do I know the range of that absolute device?
Since I could not answer these questions, I decided I needed a different approach. I tried to edit wwnd.c and handle WM_MOUSEMOVE, WM_LBUTTONDOWN, and WM_LBUTTONDOWN messages in directx_wnd_proc.
I found that I wasn't getting WM_MOUSEMOVE messages in full screen mode.
I managed to find a work around for this. GetCursorPos will work, but only if you don't initialize Allegro's mouse routines and you account for the window location in windowed mode.
So I export wnd_x and wnd_y in allegro.def, and include aintwin.h in my project. Then I can get the mouse position with this code...
Now I need to handle mouse clicks. I am getting button down/up messages so I'll use those. I add a variable to winalleg.h
And define it in wwnd.c
And add this to the switch in wwnd.c, function directx_wnd_proc.
Then export windows_mouse_b1 in allegro.def. It sort of works. Mouse is fine, you have to press really hard on the stylus to acknowledge a click, and the touchscreen does not move the cursor before you get the click message. 
Dig through WinUser.h, find messages WM_TABLET_FIRST and WM_TABLET_LAST with nothing in between them. I start capturing the messages in this range. I only find one, when I click with the stylus or touch the screen, it's undocumented message 716 (0x2CC) I figure out this is a message saying click and set the cursor at the same time. I add this code to directx_wnd_proc
The mouse up message is received as normal and everything works! I can switch between mouse and stylus and touch screen and the input is always interpreted correctly whether in full screen or windowed. Since message #716 is not documented, I'm afraid it will change in Windows 7. I haven't figured out right clicking yet either. I have not tested it in Allegro 4.4 but I checked the code and didn't see anything that would indicate a fix for this. I haven't tested or checked Allegro 5.
So that's what I've figured out. Maybe that will help with tablet/touch screen support in the future. It's at least a workaround for people who want tablet support now. Although really we should be using the tablet SDK to write a windows mouse driver. I'm just glad I finally got this working.
-Mark
uhumm...
In 4.9, we don't use DirectInput at all for the mouse code - if you want you can try if 4.9 works wit your tablet. And if it does, maybe someone will back-port the changes.
In 4.9, we don't use DirectInput at all for the mouse code
Hey, look at that. It was fixed in 4.9 sometime in the last month. From your responses, I feel like I should have known that somehow