Fun with touchscreen terminals
-
Soo, currently I have a job where I do tech support for a company producing touchscreen terminals for retailers, so you can listen to audio books or audio albums before you buy them.
For the most part it's fun, but there are some design decisions which are ... strange, to say the least.For example, the store usually has a dedicated server which downloads new content and then distributes this content to the terminals. This server also connects to the company's VPN, so you can easily SSH into it. However, it has this small problem: Losing the internet connection also makes it lose the VPN connection - but regaining the internet connection does not mean regaining VPN as well!
So, parts of the day are spent with phoning various clueless sales people and asking them to reboot the server.The terminals themselves can either be ssh'ed into - or you can use a VNC connection.
An ssh connection does not yield anything useful, though, so scratch that. In order to change configuration settings, you'll need to use the VNC, conjure up a keypad by clicking in the corner of the screen, enter a 4 digit PIN by clicking on numbers on said keypad and then you have a configuration GUI. However, during that time, neither is the screen turned black nor touchscreen input turned off.
Thus anyone standing in front of the terminal while you're connected to it, could get the PIN by simply watching the mouse's movements (the number keys are also highlighted shortly when clicking them). And they can also mess things up by touching any of the GUI buttons...Which means that today I had much fun because some guy obviously loved his Justin Bieber CDs very much. Whenever I managed to get to the configuration screen, he simply pushed the big red X in the corner, which closed the window again.
My final "solution" to the problem: ssh'ing onto the box and typing "reboot", five times in a row. Then he finally gave up and went to one of the other 20 terminals in the store (which I had already reconfigured).
And yes, there is a way to display a message on the screen: You just have to use VNC, conjure up the keypad (which also has a big red X), enter the 4 digit PIN, press another button in the configuration GUI and then type in the message...
So, does anyone have a spontaneous idea how to temporarily turn off touchscreen input (it's okay if I have to reboot to restore touch screen capabilities, though!). Something simple along the lines of "/dev/input0 > /dev/null" ;)
-
Dude - check the settings on the VNC server. All of the new ones support this AFAIK. Here's the help page for RealVNC:
Benefits | VNC® Connect
Find out how VNC Connect can reduce costs and risk, increase uptime and service quality, and enable revenue and compliance.
Anything more than that, you'll have to click this link:
(seeing as this is tdwtf, and not stackexchange, you can't downvote my smartass answer. woot.)
-
Most VNC implementations have an option to blank the remote screen when you connect.
The problem with the VPN not coming up after an interrupted connection is common. Any competent network engineer can fix it for you.
-
It seems TRWTF is you, interrupting a customer of some bussiness and potentially scaring him away, causing the bussiness to lose a customer, rather than just waiting a couple of minutes or an hour until he's gone.
As for your question, there's a gazillion different ways to solve that problem. If only there was some way to look for solutions to certain problems on the internet. Like you type in some keywords, press a button, and you get web sites containing those keywords.
-
@hoodaticus said:
(seeing as this is tdwtf, and not stackexchange, you can't downvote my smartass answer. woot.)
But neither can we downvote the lazy question :(
-
@hoodaticus said:
Dude - check the settings on the VNC server. All of the new ones support this AFAIK. Here's the help page for RealVNC:
Benefits | VNC® Connect
Find out how VNC Connect can reduce costs and risk, increase uptime and service quality, and enable revenue and compliance.
Anything more than that, you'll have to click this link:
(seeing as this is tdwtf, and not stackexchange, you can't downvote my smartass answer. woot.)
That's nice considering I'm not allowed to change the settings of the server. Also, there's a reason why I asked for a switch kind of command. Considering the fact that it's VNC on Linux, your link helped me exactly zip. Did you really think I did not try to Google? Come on, try it, google "vncserver disable keyboard" (I'll be so nice and mention it's TightVNC).
@pbean said:
It seems TRWTF is you, interrupting a customer of some bussiness and potentially scaring him away, causing the bussiness to lose a customer, rather than just waiting a couple of minutes or an hour until he's gone.
As for your question, there's a gazillion different ways to solve that problem. If only there was some way to look for solutions to certain problems on the internet. Like you type in some keywords, press a button, and you get web sites containing those keywords.
Then maybe you try to find that information? Have fun. You won't, by the way.
Furthermore, the whole thing had kind of a time limit and I had already changed all the other terminals. So it was either sitting there, twiddling my thumbs and hoping that there was enough time left when the guy finally abandoned the terminal, or forcefully disconnecting him. And we also can't change the settings while the shop is closed because they turn off the power to all appliances as soon as the shop is closed.
-
OTOH, Googling for "vnc keyboard disable" only got me 896,000 results. And "linux vnc keyboard disable" totally limited this to a mere 779,000 results.
Obviously this is what you meant by saying you won't find this information by Googling for it. I totally sympathise. >cough<
-
@Cad Delworth said:
OTOH, Googling for "vnc keyboard disable" only got me 896,000 results. And "linux vnc keyboard disable" totally limited this to a mere 779,000 results.
Obviously this is what you meant by saying you won't find this information by Googling for it. I totally sympathise. >cough<
Since when is quantity equal to quality? Did you actually take a look at those results and saw how many of them are relevant for a tightvnc server under linux?
Here's the first page:
And it only goes downhill from there.Only the second entry actually talks about the problem - and you will note that someone else asked the very same question I asked: "How do I disable remote input with tightvnc under linux?" You'll also note that he got no answer. Now, before you tell me to turn to the manual, you'll note that the first link (being said manual) has also been clicked. Let's just say it's less than helpful in that regard.So, do you really want to continue this pissing contest or do you want to admit that, yes, there might be a slight problem for me to easily disable remote input?
-
@Rhywden said:
(snip)
And yes, there is a way to display a message on the screen: You just have to use VNC, conjure up the keypad (which also has a big red X), enter the 4 digit PIN, press another button in the configuration GUI and then type in the message...
So, does anyone have a spontaneous idea how to temporarily turn off touchscreen input (it's okay if I have to reboot to restore touch screen capabilities, though!). Something simple along the lines of "/dev/input0 > /dev/null" ;)
I think along the lines of others that you are still the wtf. You said that you have ssh access to the device, so I can't for the life of me guess why you cannot either
- configure the application via command line (if you cannot that's another wtf)
- show a message to the user:
me@box $ DISPLAY=:0 echo 'This box is unavailable, please use another' | \ xmessage -center -file -
(I used continuation so the line fits in my screen, not mandatory.)
3. use xrandr to disable the local output
me@box $ DISPLAY=:0 xrandr --output VGA1 --disable
change VGA1 to whatever your device name is (usually VGA , VGA1 , LVDS , LVDS1)
4. Use ssh -X and redirect another instance of the configuration tool to your machine.
- configure the application via command line (if you cannot that's another wtf)
-
And that's a prime example of why we throw a box of soap, some beef jerky and some soda into our developer's rooms on a weekly basis and otherwise keep it locked tightly.
-
@Rhywden said:
And that's a prime example of why we throw a box of soap, some beef jerky and some soda into our developer's rooms on a weekly basis and otherwise keep it locked tightly.
I'm sorry if the last post was aggressive. I meant no offense to you but (despite tons of contrary evidence) I still have a hard time believing that anyone developing something in linux ends up doing it so backwards as the situation you described. If your developers are really of the kind that need soap or come from the other side, that is no surprise and I feel sorry.
I'm certain that my company can do it better for a quarter of the cost at the current exchange rate if you are interested.
-
@spamcourt said:
@Rhywden said:
And that's a prime example of why we throw a box of soap, some beef jerky and some soda into our developer's rooms on a weekly basis and otherwise keep it locked tightly.
I'm sorry if the last post was aggressive. I meant no offense to you but (despite tons of contrary evidence) I still have a hard time believing that anyone developing something in linux ends up doing it so backwards as the situation you described. If your developers are really of the kind that need soap or come from the other side, that is no surprise and I feel sorry.
I'm certain that my company can do it better for a quarter of the cost at the current exchange rate if you are interested.
I'm a lowly tech support grunt. That's why I searched for a solution which allows me to do that stuff without having to change configuration files or anything which does not revert automatically upon a reboot or after a powerloss.
I will have a look at your commands, thanks. The reason why I asked is not that I'm unable to use Google but that the obvious solution (use of VNC configuration) is not possible in this instance and I needed a pointer as to where to look next.
And, yes, the situation is a bit strange. Though I actually did not tell the biggest WTF (and this one should really be one without a doubt):
They also have some (Windows XP) terminals where customers can have a look at cooking receipes and print them, so that they have a list at hand of what to buy. We all know that printers do run out ouf paper from time to time. Thus the program has to recognize the state "out of paper". How does one do that? Easy: If a new printing task comes in, take a look at the printing queue first. If there's still a previous task in the queue, assume that the printer is out of paper because the task should have been finished by now, right?
Problem with that: The printer sometimes takes several seconds to become active. During that time, no feedback is given to the customer. Which means that (to the customer) nothing seems to happen after the first press of "print". What is the natural reaction by almost anyone in that situation? Right. So now we have a new printing task incoming when the first one has not cleared the queue yet...
-
@Rhywden said:
The printer sometimes takes several seconds to become active. During that time, no feedback is given to the customer. Which means that (to the customer) nothing seems to happen after the first press of "print". What is the natural reaction by almost anyone in that situation? Right. So now we have a new printing task incoming when the first one has not cleared the queue yet...
Aww, I thought it would just print anyway while the customer waddles away, and by the end of the day you'll have a huge pile of recipes people printed but never picked up.
-
i don't really know what you're talking about (none of this is my field), but could this be of some help?
-
-1
-
@Rhywden said:
And that's a prime example of why we throw a box of soap, some beef jerky and some soda into our developer's rooms on a weekly basis and otherwise keep it locked tightly.
What do they do with the soap?
-
Eat it for desert, obviously.
-
@tOmcOlins said:
@Rhywden said:
And that's a prime example of why we throw a box of soap, some beef jerky and some soda into our developer's rooms on a weekly basis and otherwise keep it locked tightly.
What do they do with the soap?
Lube.
-
@tOmcOlins said:
What do they do with the soap?
Ignore it and use REST architecture like any sane human being.
-
@Xyro said:
@tOmcOlins said:
What do they do with the soap?
Ignore it and use REST architecture like any sane human being.Well done. Thread's over, go home fellas.
-
@Rhywden said:
I'm a lowly tech support grunt.
This would explain why you think the ssh connection's useless.
Question: can you start a new instance of the vncserver from the command-line that doesn't get displayed on the customer's screen, but can run the VPN software for the system? (I'm assuming that the VPN software is GUI-only; if not, you're probably going to stay a lowly tech support grunt for quite some time. That is, someone capable of getting promoted out of that role quickly would've identified a command-line option on the VPN software.)
I'm guessing things like this are what the ssh connection's *for*. (Well, that, and forcing the system to do software updates.)
@spamcourt said:
I meant no offense to you but (despite tons of contrary evidence) I still have a hard time believing that anyone developing something in linux ends up doing it so backwards as the situation you described.
That sounds like a personal problem. I'd be willing to bet that there are people who've developed stuff in Linux and did it even more backwards than the situation Rhywden described. I'd guess at least a couple have probably already made it into thedailywtf.
Or are you admitting you've seen them, and that's part of your tons of contrary evidence? If so, I sympathize. Even at 14 years of IT experience, I was still frequently exposed to systems that were designed worse than I could imagine on my own (generally speaking, these were all things I was supposed to help evaluate for use within the company for which I was working, and none of them exist in that company at this time. Well, if you discount the one where the vendor took my 61 page defect list, and actually fixed them. But they don't have the product with over 61 pages worth of defects - or even the one with 15 pages of defects that they came back with... My replacements aren't quite the same caliber, so I don't trust their claims that there's no remaining defects, but it's a lot better than it had been.) Now, I am still surprised on occasion, but I'm able to believe it much more easily, after I've encountered it.
-
@tgape said:
@Rhywden said:
I'm a lowly tech support grunt.
This would explain why you think the ssh connection's useless.
Na, not exactly useless, but the problem is that most stuff is buried away somewhere. Or you could access it from the ssh connection, but since you have administer up to 20 terminals sometimes, it's annoying having to type more than 2 commands for every terminal. I mean, ssh into the server, grab the ip address of the terminal, ssh into the terminal, do something to whatever, connect the vnc, change the setting, reboot - and rinse and repeat for the other 20 terminals. In one location.
Question: can you start a new instance of the vncserver from the command-line that doesn't get displayed on the customer's screen, but can run the VPN software for the system? (I'm assuming that the VPN software is GUI-only; if not, you're probably going to stay a lowly tech support grunt for quite some time. That is, someone capable of getting promoted out of that role quickly would've identified a command-line option on the VPN software.)
Well, the problem is that I could start a new instance - but I'm not sure if the application itself would behave if I started it a second time.I already tried the 'xmessage' and 'xrandr' route described above, but keep running into "can't open display", "DISPLAY=:0 xinput list" works for whatever reason, oh, well. I probably should not try to care anymore due to the fact that I'll be out of there in 2 months (having finished university and doing something completely different).
Besides, I also ran into a completely new WTF today:
The company recently expanded and now have stores in the UK, China and Russia running their terminals. The procedure I detailed in my first post resulted from the misconfiguration of the master server which had the wrong timezone (UTC instead of UTC+1 or rather Europe/Berlin, for example). Which I had to do for all the "discless" terminals without a harddisc - adjust the server's timezone, adjust the terminals' shutdown times and reboot them so they get the correct time as well.
When I connected to a server in Moscow, I accidentally connected to a terminal with a harddisc. Which also had the wrong timezone of UTC+1 this time. Moscow is UTC+3. So I changed the server's timezone, rebooted the terminal ... and saw that the terminal was unaffected. Of course! It had its own harddisc which meant that it stored its configuration locally! Using the same method I used for the server, I simply did a "cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime", ran "date" and saw that everything was fine, the terminal's system time was now correctly attuned.
Or so I thought. Upon connecting with VNC, I saw that the application was still on UTC+1. Maybe a restart of the application would fix it? Nope. Reboot? Nope. Let's try the application's "set time" command. It was set to 17:00h at the moment, so I set it to 19:00h, clicked "ok"... and the time was still at 17:00h. Okay, there's a different button named "use system time" - which opened a GTK window where I could select the timezone. Which was set to "Europe/Berlin". Upon choosing "Europe/Moscow", the time was now set to 15:00h. Trying to set it to 19:00h resulted in an application time of 17:00h (with the command line's "date" resulting in 19:00h). So, in order to get the application to display 19:00h, I had to set the time to 21:00h, just to have it revert back to 19:00h (system time being now 21:00h, however).
I'm a bit confused and honestly a bit frightened if I think of what might be going on in the application's logic.
-
@Rhywden said:
Or so I thought. Upon connecting with VNC, I saw that the application was still on UTC+1. Maybe a restart of the application would fix it? Nope. Reboot? Nope. Let's try the application's "set time" command. It was set to 17:00h at the moment, so I set it to 19:00h, clicked "ok"... and the time was still at 17:00h. Okay, there's a different button named "use system time" - which opened a GTK window where I could select the timezone. Which was set to "Europe/Berlin". Upon choosing "Europe/Moscow", the time was now set to 15:00h. Trying to set it to 19:00h resulted in an application time of 17:00h (with the command line's "date" resulting in 19:00h). So, in order to get the application to display 19:00h, I had to set the time to 21:00h, just to have it revert back to 19:00h (system time being now 21:00h, however).
I'm dizzy.
-
@Rhywden said:
I already tried the 'xmessage' and 'xrandr' route described above, but keep running into "can't open display", "DISPLAY=:0 xinput list" works for whatever reason, oh, well.
(...snip...) Which was set to "Europe/Berlin". Upon choosing "Europe/Moscow", the time was now set to 15:00h. Trying to set it to 19:00h resulted in an application time of 17:00h (with the command line's "date" resulting in 19:00h). So, in order to get the application to display 19:00h, I had to set the time to 21:00h, just to have it revert back to 19:00h (system time being now 21:00h, however).I'm a bit confused and honestly a bit frightened if I think of what might be going on in the application's logic.
Well, that is very very odd. If xinput works it's opening the display, so xmessage and xrandr must work too. (I guess you did 'xinput list' and it showed the input devices , right?). For doing the same task in many machines there are tons of programs to do that.
Timezone: please don't play with the guts of a system like that. As root use the command 'tzselect', fill /etc/timezone accordingly , then do the copy if tzselect didn't. Also, you may have an ntp client installed.
have a nice day
-
@Rhywden said:
I already tried the 'xmessage' and 'xrandr' route described above, but keep running into "can't open display", "DISPLAY=:0 xinput list" works for whatever reason, oh, well. I probably should not try to care anymore due to the fact that I'll be out of there in 2 months (having finished university and doing something completely different).
Well, just to round off your university education, the "DISPLAY=:0" part is defining an environmental variable which X programs use. When you ssh in, the DISPLAY is probably set to your local machine (which is remote to the touchscreen terminal), but since you want the X program to use the touchscreen terminal, you need to explicit set it to :0. This makes it use the zeroth display of the local environment. DISPLAY and any other environmental variable can be changed by either prefixing the command with the assignment to change it temporarily or executing "export DISPLAY=:0" to change it for the shell session. (You can check the value of the variable with "echo $DISPLAY".)
-
@Xyro said:
@Rhywden said:
I already tried the 'xmessage' and 'xrandr' route described above, but keep running into "can't open display", "DISPLAY=:0 xinput list" works for whatever reason, oh, well. I probably should not try to care anymore due to the fact that I'll be out of there in 2 months (having finished university and doing something completely different).
Well, just to round off your university education, the "DISPLAY=:0" part is defining an environmental variable which X programs use. When you ssh in, the DISPLAY is probably set to your local machine (which is remote to the touchscreen terminal), but since you want the X program to use the touchscreen terminal, you need to explicit set it to :0. This makes it use the zeroth display of the local environment. DISPLAY and any other environmental variable can be changed by either prefixing the command with the assignment to change it temporarily or executing "export DISPLAY=:0" to change it for the shell session. (You can check the value of the variable with "echo $DISPLAY".)Of course I prepended the DISPLAY=:0 (and also DISPLAY=:0.0 and DISPLAY=localhost:0.0, just to make sure) to every command.
@spamcourt said:Well, that is very very odd. If xinput works it's opening the display, so xmessage and xrandr must work too. (I guess you did 'xinput list' and it showed the input devices , right?). For doing the same task in many machines there are tons of programs to do that.
Timezone: please don't play with the guts of a system like that. As root use the command 'tzselect', fill /etc/timezone accordingly , then do the copy if tzselect didn't. Also, you may have an ntp client installed.
have a nice day
Well, that's what I found. xinput worked, xrandr and xmessage didn't.
As for the timezone, why exactly should I not copy from /user/share...? That's the default way to do it under Gentoo and when googling for "setting timezone linux" at least half the pages point to this method (or at least setting a symbolic link to /usr/share...). I'm not exactly sure what is so dangerous about that. I certainly did not find any dire warnings against doing that.
-
@tgape said:
@spamcourt said:
I meant no offense to you but (despite tons of contrary evidence) I still have a hard time believing that anyone developing something in linux ends up doing it so backwards as the situation you described.
That sounds like a personal problem. I'd be willing to bet that there are people who've developed stuff in Linux and did it even more backwards than the situation Rhywden described. I'd guess at least a couple have probably already made it into thedailywtf.
Or are you admitting you've seen them, and that's part of your tons of contrary evidence? If so, I sympathize.
That last one. I'm learning neuroscience at community college to remove the part of my brain that holds that kind of memories. In my last 'big' job I was called in as the Open Source Guy but anyone who read five minutes about version control and managed to compile ffmpeg from source could run circles around the rest of the team. I left after a couple of months not wanting to reach 30 and having to maintain such a monster. And worst, somehow they managed to get the product on the street and it works. Unless you look inside and realize that a mini-itx board with mythtv outperforms it.
Anyway I left for greener pastures and now I'm in a startup with fellow freetards developing hardware and free software. It couldn't be better.
-
@Rhywden said:
@spamcourt said:
Well, that is very very odd. If xinput works it's opening the display, so xmessage and xrandr must work too. (I guess you did 'xinput list' and it showed the input devices , right?). For doing the same task in many machines there are tons of programs to do that.
Timezone: please don't play with the guts of a system like that. As root use the command 'tzselect', fill /etc/timezone accordingly , then do the copy if tzselect didn't. Also, you may have an ntp client installed.
have a nice day
Well, that's what I found. xinput worked, xrandr and xmessage didn't.
As for the timezone, why exactly should I not copy from /user/share...?
Well, some programs like to read /etc/timezone and do whatever they please. Also, there's the environmental variable TZ.
As for X not working I'm confused. Are you ssh'ing with 'ssh -X remotemachine' ?
-
@Rhywden said:
@tgape said:
@Rhywden said:
I'm a lowly tech support grunt.
This would explain why you think the ssh connection's useless.
Na, not exactly useless, but the problem is that most stuff is buried away somewhere. Or you could access it from the ssh connection, but since you have administer up to 20 terminals sometimes, it's annoying having to type more than 2 commands for every terminal. I mean, ssh into the server, grab the ip address of the terminal, ssh into the terminal, do something to whatever, connect the vnc, change the setting, reboot - and rinse and repeat for the other 20 terminals. In one location.
It's called a shell script. Basically, you write your commands into a file. This may be a little trickier than just typing the commands directly, if you need to have it figure out IP addresses or something. However, you then copy the file to all of the boxes and run it there. In the scenario you've depicted, it'll then open the vnc window for each in sequence (you're not running them in the background, right?), and you just have to repeat the GUI interaction. Because GUI interactions tend to be a bit too annoying to script for just 20 boxes.
@Rhywden said:
...I'm not sure if the application itself would behave if...
It's called a test environment. Oh, you don't have one. Sigh.
@Rhywden said:
The procedure I detailed in my first post resulted from the misconfiguration of the master server which had the wrong timezone (UTC instead of UTC+1 or rather Europe/Berlin, for example).
There's actually a fairly good argument for having all of your servers in UTC: if all of your servers are on the same timezone, you can correlate your logs easier, when you need to compare different logs from different systems for some reason.
@Rhywden said:
I simply did a "cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime"
On a normal system, this would've messed up the system's idea of what UTC+1 is. Hint: On many systems, /etc/localtime is a symbolic link. Hint 2: On most systems, copying a file onto a symbolic link replaces the file the link pointed to. But it wouldn't have set it up for the fun you then described. WHEEE!
Finally, as another poster mentioned, there's the TZ environment variable, and many processes cache the local timezone at start time (either from TZ or from /etc/localtime or /etc/timezone) and keep it forever, because the timezone doesn't change while the system's running, right? Note: Every laptop I've ever owned proved that misconception wrong. Just updating the /etc timezone file for your system won't do anything about any of those. Oh, and there's also the possibility of a file in /etc/default (such as login, defaults, timezone, zoneinfo, locale, etc.) setting a TZ environment variable for either the whole system or just *some* processes. I've frequently seen this last bit to make a setup where the system considers itself to be in UTC (or Arizona, or some other place that doesn't do daylight savings time), but all of the user processes think they're in the timezone the system is physically located.
Theoretically, tzselect should compensate for as many of those potentials on your system as can reasonably be handled, so long as it hasn't been tweaked all out of shape by a local admin.
LMGTFY - Let Me Google That For You
