Adafruit touchscreen (AR1100)

Can you tell which works and which not?

Thanks a lot.

The only one working is made by http://home.eeti.com.tw
I also tried one from http://www.data-modul.com. This one freezes the OS.
One is coming with the display it’s a iiyama.
The last one I bought from RS but it’s made by http://www.penmount.com/capacitive_1.php
With the 2 last ones, the mouse icon is not moving.
I have to investigate to understand why EETI works and the other one don’t when they are supposed to use the same protocol…

when they are supposed to use the same protocol

That’s the problem.
They are supposed to… but with many variations :)

I try to use with my RPi this Chalk Display and with my xM or Beagle C4 a comparable Display but with this PCB v2. “Touch” is connected via USB but it do nothing on both but !USBInfo or *USBDevices can see.

I forgot to say that all the 4 touch screen are working with the Raspberry Pi and raspbian. Chris code is only working with a few touch screen when it should be working with all of them since he has changed RISCOS mouse pointer into a protocol with absolute coordinates. At least it’s what I understood?

I saved my HIDdescriptor-file via !USBInfo. It looks like my screen(s) are not detectet as a i/o-device or what ever.
I will search for more information…
Thanks a lot.

I forget… I have not try with RPi and Linux but with Linux and a other Board. Display ok and than I plug the “Touch” it freeze. I think I try it with the RPi at the weekend.

It’s difficult to say what the problem is. During testing I had a couple of crashes, which were due to dividing by zero. I wonder whether Chris’ most problematic panel is returning nothing for its bounds¹, resulting in a crash. That doesn’t explain the other ones that simply don’t work, but it may explain the crash.

¹ If it’s a fixed-resolution touchscreen then it theoretically wouldn’t need to provide its bounds if each touch point was mapped to one pixel. The OS could already know the resolution – and therefore the bounds – via EDID data.

During testing I had a couple of crashes, which were due to dividing by zero. I wonder whether Chris’ most problematic panel is returning nothing for its bounds, resulting in a crash.

I should have accounted for that in some tweaks I made to your code before submitting. If the bounds aren’t found or are zero then it should ignore the device (you can see the updated code here)

I should have accounted for that in some tweaks I made to your code before submitting. If the bounds aren’t found or are zero then it should ignore the device

Diagnostically, of the 4 that Chris tested 2 did nothing (guess here that those have have unfound or zero value bounds, for tests it might be useful to have a means of supplying a set of bounds as a default)
The intriguing item is the unit that freezes the OS (or at least freezes the GUI – access to something like a shared disc would diagnostically show the OS operational and the GUI locked or not)

The intriguing item is the unit that freezes the OS

It subtracts the lower bound from the upper bound, and then divides by that. If both bounds are the same, or both are zero, then it’ll crash due to division by zero.

The “doing nothing” panels are the interesting ones :)

If both bounds are the same, or both are zero, then it’ll crash due to division by zero

But as Jeffrey pointed out, he altered the code so that zero bounds are presented or not present at all then the device should be ignored.
The only crash for a divide by zero is upper = lower.

Note all on logic, rather than code examination.

Doing nothing is likely to be Jeffrey’s alteration catching a bounds = 0 or not presented (or not presented in a meaningful way)
Defaulting to a usable value set is probably the best option. How you notify the user that it is the default set is the question.

But as Jeffrey pointed out, he altered the code so that zero bounds are presented or not present at all then the device should be ignored.

English is a pain :)

I misinterpreted “should have” as “meant to”. It seems that the code does check for upper = lower too. However, I’m not sure what actually happens when it detects that the figures match; it prints a debug message then… does something called “USB_ATTACH_ERROR_RETURN”. If that’s bailing out of the code then could it possibly have broken the normal mouse?

Second Try. One point for the wishlist. Do not lose all the text when the login is lost during writing a answer.

Temperature near 40°C… a life in slow motion ;-)

My screen works with Raspian. The dmesg output. Ortek is the Mouse/Keyboard, N-trig DuoSense the touchscreen.

Does PtrTest give any values when you touch the screen? It should work with both “new” and “old” ROMs, and you just need to run the !RunImage.

Is it changed? I download last week and it works not. Only zeros in X and Y. Also with the Beagle display.

Nope, it’s the same one that I uploaded in March. It looks like your earlier comment was right:

It looks like my screen(s) are not detectet as a i/o-device or what ever.

Unlike mine, yours isn’t acting like a mouse and is therefore completely bypassing the new code :(

It looks like there is a new firmware (May 2015) aviable. Fixed any HID problems.
I will try to change but it take same time.

The firmware update seems a little more complicated than I thought. :-( The new firmware is for my revision of the touchscreen but the todo at the Support page does not. I do not find the jumper to get the microcontroller board to the bootloader mode.
The layout is not the same, the jumper shown does not exist in my revision. Requests the Chalk support remain unanswered so far.

No answer from the Chalk support (Mails, Forum)… :-(