Disable H2O touch screen double click???

[Bob Brunius]

I have a display application photo running using the built in browser. It works really well but the last issue I can't seem to fix is that when it rains the drops make the reader think it was double clicked and the zoom level changes.

I've tried intercepting the double click using javascript but that experimental doesn't have dblclick() or touchstart() functions.

Is there some way in the config file maybe to shut off the double click zooming?

[Bob Brunius]

bump..........

[davidfor]

Sorry, haven't seen anything, which is probably why you didn't get a response before. I also doubt that it is something that has worried about. But, have you tried turning off the droplet detection in the settings?

[frostschutz]

In software, I don't think there is any you can do from a webpage html. Unless the browser has a bug that makes it lock up, it's not possible to block the inputs, after all there has to be a way to go back to the main menu?

If you have a way to run a script on the Kobo itself (maybe via my WebPortal mod, using a custom CGI script?), you can disable the touchscreen like such:

# ls /sys/bus/i2c/drivers/zforce-ir-touch/
0-0050  bind    uevent  unbind
# echo 0-0050 > /sys/bus/i2c/drivers/zforce-ir-touch/unbind

That tells the touchscreen driver to unbind ("unplug") the touchscreen in software so it no longer works. To recover touchscreen functionality, you have to reboot.

You could also do this in hardware. An 8" screen protector that covers the entire bezel might prevent all touches. But if you're using this on a boat, I'm not sure how well that works in wind and weather and whether it would obstruct screen visibility. Or a waterproof bag for the entire device that doesn't come in contact with the screen. You could also use something soft/opaque around the screen borders to blind the IR touch entire.

[Bob Brunius]

Could a demon be started at boot which if it detects the browser starting up then runs the code you suggest.

The other approach I was thinking of was reading the browser's cookies to trigger scripts. The screen brightness is one other thing I would like to control via javascript in the browser also.

[frostschutz]

As for the frontlight control, this oldie still works for setting brightness 0-100:

https://www.mobileread.com/forums/sh...d.php?t=200706

As for JavaScript, again have a look at my WebPortal mod, if you can use JavaScript to fire a http request to http://webportal/cgi-bin/... the WebPortal would run a cgi-bin shell script for you that does the things you want. So you could both disable touchscreen, and change light, whenever you want using JavaScript with cgi-bin helper.

[Bob Brunius]

I tested the command to disable the touchpad and it works. Thanks for that. Might there be a way to reattach the driver later without a restart?

I thought that using browser cookies would be a possible route to staring bash scripts to controlling stuff. Apparently though the browser doesn't write cookies to the files system. Close the browser and the cookies are gone.

I'm warming up to your webportal concept. My application html file is already a local file that loads by entry in config. The data is brought in from the remote server using cross domain jsonp call which works on the minimally featured browser.

[frostschutz]

Originally Posted by Bob Brunius

I tested the command to disable the touchpad and it works. Thanks for that. Might there be a way to reattach the driver later without a restart?

I haven't looked into it. But my guess is - no. Even if you managed to tell the driver to re-bind that device, the handle nickel has on the touchscreen would probably no longer be valid and nickel won't know to re-open it. Just guessing. And if you have to kill and restart nickel you might just as well reboot.

Originally Posted by Bob Brunius

I thought that using browser cookies would be a possible route to staring bash scripts to controlling stuff.

There are some log messages and I've done such things before but that's not a very stable solution (like log messages change in between firmware versions).

Originally Posted by Bob Brunius

I'm warming up to your webportal concept.

It should work, esp. since you're already in this browser environment.

The CGI scripts included with webportal are all apps that produce html for a user interface, in your case you'd just have to fire some event or other so yours should be simpler. It's based on busybox httpd so you should also be able to find other cgi examples for that online.

[pasquale8120]

Question about your sailing app.
How did you prevent the browser from doing the fancy refresh with all the flickering?
I tried pointing the browser at a JS "gauge" on the web and every few updates
the whole screen flashes.

[frostschutz]

Using only pure black&white imagery might help a bit, "color" (16 level grayscale) requires more effort for refreshing

[Bob Brunius]

Originally Posted by pasquale8120

Question about your sailing app.
How did you prevent the browser from doing the fancy refresh with all the flickering?
I tried pointing the browser at a JS "gauge" on the web and every few updates
the whole screen flashes.

I'm using javascript in the browser to replace the html contents of certain <div> elements when they need updating. I'm not getting the whole screen flashes that you mention. The browser only replaces part of the screen. It does not do a full screen refresh.

[kido.resuri]

Would you release the display application you have?