Strange Official Touchscreen Problem - SCUMMVM / DOSBox


I’m having an entirely ridiculous problem and nobody seems to have a solution for me. In fact, I can’t even find anyone having the exact problem that I am. My touchscreen works fine in most situations, but for whatever reason, in full screen applications, the touchscreen causes the cursor to make a b-line for the bottom right corner of the screen with the speed at which it ends up there varying depending on how far down and to the right you touch it. I’m inexperienced and this is my first build for a Pi system, and it’s really driving me up the wall.

Is installing from NOOBS really the problem here? After all, I followed the official website’s installation instructions including the update and upgrade instructions, as well as the instructions on this page (which appear to be the only thing even remotely close to the issue I’m having). Whatever the case, I could really use some help, as my touchscreen is largely useless for this if I can’t use it in things such as DOSBox or ScummVM.

Official 7" Raspberry Pi Touch Screen FAQ

Ahoy, sorry your post got a little lost in the noise of the Touchscreen FAQ. I’ve split it out into another thread so we can better get to the bottom of the problem.

I was, I admit, entirely perplexed until I read “DOSBox” or “ScummVM”. I’m familiar with both of these, since I’m a bit of a fan of Commander Keen and Simon the Sorcerer to name but a few- I was a bit late to the DOS game, admittedly.

What you describe sounds fairly typical of these applications, and isn’t a problem with NOOBS, or the Touchscreen, but rather with the individual software and how it handles input.

Things like DOSBox or ScummVM in fullscreen will usually glom onto mouse input and try to handle it in their own way. When it comes to things like Multi-Touch, a generic Linux build of either will probably be a total trainwreck. You’ll find platform specific patches for these on things like Android, and the OpenPandora console, which fix these problems in specific cases.

In fact, you can find a very, very similar problem described by Quietust back in 2014 on this thread:

I have this same problem on my Surface Pro - when in fullscreen mode, all touch input is interpreted as relative motion from the center of the screen (e.g. if I touch the left side of the screen, the cursor moves to the left, and if I touch the right side of the screen, the cursor moves to the right).

I’ll have a dig around and see if I can find a solution. Some people have proposed changing SDL itself to better handle relative input like touch screens, but that sounds a bit drastic!

There will be a fix, somewhere!


I was kind of afraid of that, truth be told. Hopefully somebody can help me come up with a solution, because I’d love to be able to play some adventure games and good old Lemmings with this touchscreen. If it helps any, another one to note is the Pi version of Free Heroes 2. Also, oddly, DOSBox is the odd man out in this as it’s the only one of the three with the issue that also spazzes the mouse out when it’s in windowed mode… assuming that’s because DOSBox locks the mouse into its window.

Unfortunately, it looks like I’m going to have to reinstall everything anyways due to some sort of screwup while attempting to use rpi-update to update the kernel at the behest of another site discussing the touchscreen… now it stops me at a login screen on boot and putting in “pi” and “raspberry” makes the screen blank momentarily and return back to the login screen.


I compiled SCUMMVM from source yesterday and had a responsive cursor full-screen, however I couldn’t actually click on anything. I wont have time to look into it for a week or so (I’ll be away) but it looks like left/right mouse button simulation could be borrowed from the Android or OpenPandora ports.

I think the list of people who care about getting these games running well on generic linux touchscreen devices is probably quite short, so solutions might not be readily available. Worth having a google, though.

rpi-update is bad news! Although you can revert a broken, unbootable Pi in some cases just by replacing the contents of /boot with:


It’s been over a week, so I figured I’d check in and see if you had any more ideas on the subject. Still no solution found on my end, so I’m assuming this is going to have to be looked into by somebody more programming savvy than myself.