Bongofish
August 18, 2018, 03:10:50 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: You can attach photos hosted by the forum rather than using an external image hosting site, this means they will stay forever and not disappear after a year or two.
 
   Home   Help Search Login Register  
Pages: 1 ... 5 6 [7] 8 9
  Print  
Author Topic: Using a tablet laptop and digitizer?  (Read 53937 times)
AmbiDextrose
Full Member
***
Posts: 74


View Profile
« Reply #90 on: August 14, 2010, 10:43:04 AM »

Are you refering to the TPC drivers or something else?

Did you install the VCP (virtual COM port) drivers from FTDI? If not, you can get them here:

http://www.ftdichip.com/FTDrivers.htm

This will create a virtual COM port out of an existing USB port. I haven't installed the drivers myself but this is probably the first step in getting the serial digitizer to talk to the PC. Otherwise, it could be due to a problem with the initial handshake (e.g., PnP) between the digitizer and Windows or the WACOM drivers.
« Last Edit: August 14, 2010, 10:48:01 AM by AmbiDextrose » Logged
bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #91 on: August 14, 2010, 12:21:56 PM »

I think UnderSampled already saw data appearing on his virtual serial port using a serial terminal software. The issue is the driver installer: it won't even install!  It tries to recognizes that this is a TabletPC (and fails since it isn't one) -- but I do not know what it is looking for so we can make it to install anyway. Maybe we could try to find some sort of utility that could "trace" what calls the process is doing (which registry key it is looking up, files on disk, etc.).

Installing the HID driver is actually an interesting idea. Maybe some of these drivers could be found on Toshiba site too, I mean on toshiba there might be a serial port address "targeted" at a certain com port?  I suppose it is COM1 since the SuperIO chip only had 1 UART.

Ambidextrose: you have a running TabletPC setup -- what is the hardware resource the tablet is using? (I/O port, IRQ) it might actually match COM1.

The other question, is how does the driver will know on which port to look at, (maybe it will automatically scan all ports) but maybe it also looks at how the HID driver is configured(?). The other possibility is that maybe the driver is actually "hooking" to the HID driver infrastructure (as a filter) instead of directly accessing the COM port -- that would explain why it won't install actually.

Good thinking about Linux: I do not see why it wouldn't work, the drivers on linux are the same drivers for tabletPCs and standard Wacoms. This will prove that it works well from an electronic side of things. It would be nice that you "document" what you did to make it to work on Linux -- including making sure the FTDI "VCP" was up & running?

Another thing: if the FTDI "buffers" data too much before sending it to the USB port, it might affect the proper Wacom operation -- (this is Wacom's claim, not mine) -- That would be why a lot of the serial to usb adapters out there do not work for a Wacom tablet.  I assume that if there is such a problematic buffer in the FTDI that it could be reduced to a minimum or turned off.
« Last Edit: August 14, 2010, 04:47:38 PM by bernard » Logged
UnderSampled
Jr. Member
**
Posts: 54



View Profile
« Reply #92 on: August 16, 2010, 08:15:12 PM »

Here is a simple way of testing that output from the digitizer works (it does on mine!):

  • Download and burn a Linux live CD/USBdrive (Here's one you can use)
  • Open a terminal (you can find one in the program's menu, or if you are completely lost, press CTRL+ALT+F2 (to get back to the desktop press CTRL+ALT+F7).
  • Run the command "wacdump -f tpc /dev/ttyUSB0"

More information on how to use wacdump is available here.
Logged

AmbiDextrose
Full Member
***
Posts: 74


View Profile
« Reply #93 on: August 17, 2010, 07:14:56 AM »

Well, it sort of works under Windows XP/SP2. However, the digitizer is being recognized as a Microsoft serial mouse. It's also very intermittent- I suspect that the PnP information is getting mangled somehow. Also, the cursor becomes very jumpy when I move the pen. But the buttons do work so, at least, that's something. I still can't get the WACOM TabletPC minidrivers to install- this falls back to my suspicion that PnP isn't working correctly so the device cannot register properly.

Currently playing with the VSP's driver settings like buffer size and other options. Hopefully, this will work and we won't have to write our own drivers.
Logged
AmbiDextrose
Full Member
***
Posts: 74


View Profile
« Reply #94 on: August 19, 2010, 12:18:22 AM »

I think I figured out why the digitizer isn't functioning properly on WinXP- it has something to do with the installed drivers. On a regular TabletPC install, there are drivers named serial.sys and wisdpen.sys. The second driver (i.e., wisdpen.sys) is responsible for serial pen/tablet devices- this is not getting installed properly using the TabletPC minidrivers from WACOM. I'll have to re-assemble my TabletPC to see how the drivers are installed and see of there are any more dependencies. This will probably take a while.
Logged
UnderSampled
Jr. Member
**
Posts: 54



View Profile
« Reply #95 on: August 19, 2010, 02:16:51 AM »

The minidriver is just the windows default driver for Wacom tabletPCs. I am guessing then that the penabled driver replaces it once it's installed. The problem lies in what device it installs on. Both the minidriver and the penabled drivers install only when either it is a USB tablet (with correct ProductID and VendorID), where it does not add the drivers for a serial port, or if the serial port is named WAC004 under the ACPI (there are several other names other than WACF004, but all are still under ACPI). Being ACPI means that the serial port is controlled by the motherboard/BIOS, and not from a USB serial converter. It may be possible to add the driver in addition to the ftdi drivers on the serial port by making a custom INF, but I am not sure. It may be easier to write a simple application that runs in the background whenever you want to use the tablet, but one would need to know how to interface with windows to create pen pressures. Again, I am not sure.
« Last Edit: August 19, 2010, 04:28:00 AM by UnderSampled » Logged

bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #96 on: September 01, 2010, 08:32:58 AM »

Hi guys, I am back.  -- so we are at the driver/software stage now. It feels we are so close to a solution (for Windows) -- but this also reminds me of the 80/20 'rule': it takes 80% of the time to do the remaining 20% Smiley .

Quote from: UnderSampled
  Both the minidriver and the penabled drivers install only when [...] the serial port is named WAC004 under the ACPI

How did you learn about the driver looking at the ACPI stuff?
Logged
UnderSampled
Jr. Member
**
Posts: 54



View Profile
« Reply #97 on: September 02, 2010, 01:13:08 AM »

Welcome back Bernard!

I have learned this:

  • A USB to Serial converter is not the same as a serial port. While they can both be accessed as a COM port, the hardware, and thus the drivers they use are entirely different. ACPI stands for "Advanced Configuration and Power Interface", and is done by the BIOS. The Wacom drivers are written for a normal motherboard serial port. One that the BIOS has control of and can name. Hence the ACPI/WACF004 instead of a normal ACPI/PNP0501
  • There are various drivers for traditional (non penabled) serial tablets, some of which can work on a COM port. http://vtablet.com/ http://www.wacom-components.com/english/download/index.html
  • The only way to act as a Tablet (add pressure to the mouse, etc) in windows is to be use a driver. Said driver could could gather data either directly from hardware, or be controlled by a application/service. The drivers in the previous bullet work with a separately running service. My plan is to make my own of these based upon the linux drivers, and eventually create a driver to go with it. I am currently working on just getting data from the tablet. I f I am successful with that, I will proceed to have it control the cursor's location (without pressure).
  • The HID minidriver mentioned before at http://msdn.microsoft.com/en-us/library/ff553742(v=VS.85).aspx is actually the source code for a version of the driver that windows installs automatically for tabletPCs. It comes as one of the examples the come with the Windows Driver Development kit (find it in WinDDK\src\input\hiddigi\WacomKMDF). Interestingly, it's architecture is such that it seems relatively easy to swap out the hardware interfacing code with something that would be accessed from an application/service.

I post any updates. Hopefully I haven't gotten in over my head.
Logged

bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #98 on: September 02, 2010, 06:04:04 AM »


If I understand correctly, you are trying to build a full-blown Wacom driver.

I recently went through reading on the DDK/KMDF/etc to see if something could be done in Windows. The architecture is really nice (you can hook a third-party filter in the middle for example).

I would say the following:  the microsoft HID minidriver does support all the Wacom features up to the rotation. 

The main issue with all this is WinTab.  AFAICT, WinTab is a closed specification under "NDA" protection (especially the most recent versions). It is complex to implement (quirky) and costly (to license). The microsoft effort with their HID stuff is to get rid of WinTab and all its problems (legal and technical). But, if I understand correctly, most of the "hot" applications uses WinTab (like Photoshop). In the future, I hope all applications will migrate to the Microsoft solution, but still.  I recent tablet maker got bitten by users because it did not have a WinTab implementation. After a lot of debate, he finally "complied" and announced it will support WinTab. (can't remember the name of the tablet!).  Adobe wouldn't move to fully support microsoft solution.   DISCLAIMER: this information might not be accurate, I find it difficult to find the "true" story.

Logged
UnderSampled
Jr. Member
**
Posts: 54



View Profile
« Reply #99 on: September 16, 2010, 09:05:30 PM »

Huge Update!

First, as to the status of the hardware:

I tested Amperage of the digitizer (while running, and the pen near and reporting), which came out at 26.4mA -- Lower than the maximum 50mA for the FT232RL USB to Serial converter's internal regulator.

Somewhere during this process I accidentally (I know. I need to be just a little bit more mindful) gave the digitizer a direct 5 volts, and it still seemed to work (reporting and all). I did not test it like this long (even though it was only a while after I stopped powering it that I realized my mistake), so Unless you know that a different TabletPC provides 5 volts, I would go with the 3.3v's anyway (that's what I'm doing).

I then wired the digitizer directly into the tiny breakout board for the FT232RL. The electric-taped wires are not connected together, just wrapped together to keep everything organized.

* IMGP5115.JPG (284.71 KB. 1504x1000 - viewed 727 times.)


* IMGP5117.JPG (168.53 KB. 1504x1000 - viewed 639 times.)


I now consider hardware communication with penabled digitizers finalized.


And now for the good part!

I have successfully created -- not without help from those around me who have more experience with C -- An application that acts like wacdump for Windows, with the added feature of moving the cursor and executing clicks (without pressure information). It currently only supports penabled tablets, but it should be very to add support for other serial tablets.

It is currently hard-coded to communicate on COM2, but that code can be changed easily. If you want to use the binary, just change the com port of your serial converter in it's device manager property pages.
Another quirk it currently has is that it processes all inputs, even when it has gotten behind, which may be annoying since tablets are absolute input devices. If it get's to far behind -- which doesn't happen too often -- just remove the pen from the screen, as data is only sent when it is near.

Note that (as I just said) it does NOT support pressure. This is due to the fact that it is NOT a driver, nor does it interface with a driver. I hope to create such a driver that I can interface this program with to include pressure capabilities, but that is for later.

And now for the all important links:

Binary: http://github.com/downloads/UnderSampled/SerialTablet/SerialTablet.exe
Source code: http://github.com/UnderSampled/SerialTablet

« Last Edit: September 16, 2010, 11:08:46 PM by UnderSampled » Logged

bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #100 on: September 17, 2010, 12:03:54 AM »

WOW!

thanks for getting that amps reading. This can be useful in planning other builds.

So you did a small app that reads those serial packets, very cool!  Smiley

I certainly do not want to discourage you, but making up a driver -- especially a WinTab-compliant one is quite an undertaking I think. 

On the other hand, the Microsoft HID driver wouldn't work right off the bat?  I think all the source code is there to recompile it as a sample (you need the Windows DDK). So adapting a Ultrapad code to read tabletPC should be straigthforward.  Of course that is not WinTab compliant, but it does support all the features like pressure, rotation et al.
Logged
UnderSampled
Jr. Member
**
Posts: 54



View Profile
« Reply #101 on: September 17, 2010, 06:20:56 AM »

As I said before, all drivers for penabled tablets except my own pseudo-driver communicate directly with the motherboard's serial port hardware, as opposed to a COM port. Since the FTDI USB serial converter defaults to creating a COM port, I deemed that it would be much easier to use it that way, and I believe it was and is.

If during the process of creating a virtual driver (one that pretends to be a tablet based upon input from an API I would make) I fine that it would be quite easy to interface with the USB converter in the driver, I very well may, as there are many layers to be gone through between the FT232-RL chip and data read in an application. In any case, what I have now is enough to suit me, especially if I find some way of controlling pressure. Perhaps I can directly affect the size of the pen in Photoshop without a tablet?

P.S. Apparently this thread now has more than a hundred posts in it.
Logged

bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #102 on: September 17, 2010, 09:23:13 AM »

At first reading your post, I did not correctly understand that you are actually controlling the mouse within Windows (and not just within your little application) and thus you do have a working setup (minus the pressure)! That's really awesome (double WOW!).

I understand that you can't do pressure because the ::SendInput(mouse_event) API you are calling does not support such a parameter.

Back to my HID driver: Yes, I understand all those drivers look at the hardware ports.  But here I am talking about a working sample with the full source code (part of the Windows DDK), what I was trying to say is to slightly modify that driver source code to read the bytes from a (virtual) COM port instead of looking at the hardware port and recompile it. But before investing time playing with the DDK, I want to know if Photoshop recognizes tablets that implements the Windows Pen API (non WinTab). It didn't for a long while, but did they fix it? I can't seem to find a clear answer. If not, then that augmented driver would be as good as your little (but amazing) app!  Grin  This is where I stand with all this.
Logged
UnderSampled
Jr. Member
**
Posts: 54



View Profile
« Reply #103 on: September 17, 2010, 04:27:13 PM »

Here is a video demo of it working as a non-display tablet:

http://www.vimeo.com/15053360

The whole video (for some reason I don't really know) is rather jerky, so it's hard to show the quality of motion. Oh well.
« Last Edit: September 17, 2010, 04:29:09 PM by UnderSampled » Logged

bernard
Administrator
Hero Member
*****
Posts: 2590


pato mania


View Profile
« Reply #104 on: September 18, 2010, 02:00:49 AM »

uber cool!  Smiley I really like the huge text display! Grin

How is map the eraser? - middle button mouse to rotate the display in Blender? -- very clever!

Am I right in thinking that for "CAD" stuff, you seem to have everything you need? (Other than the little tweaks like you were talking about - too many events stacking up).

Logged
Pages: 1 ... 5 6 [7] 8 9
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!