Does waitKey() work correctly in Linux?
Porting a OpenCV program from Windows to Linux and found that the value returned from waitKey() had to be "%256"'ed. Looked at the docs and OpenCV is of type integer: http://docs.opencv.org/modules/highgui/doc/user_interface.html?highlight=waitkey#int%20waitKey%28int%20delay%29 So, is the waitKey() method broken in Linux. Or is there a reasonable explanation as to why this method works differently between Windows and Linux.
-thanks
Yeah, the web interface appears to be buggy (for me at least). I couldn't get rid of the suggested posts which obscured the entire TEXT window. So it left me with posting a blank question (where did "strong text" come from) and editing it afterwards.
%255, btw. (or 0xff)
@berak: %0xff will give a value between 0 and 254. I'll think it should be %256.
aww, sorry, i indeed misread it.
if your os is returning scankeys instead of ascii, you'd want to mask the lsb, and this is: key & 0xff;
(modulo is the wrong answer anyway.)
I use this command a lot in Linux, and as far i know, it does return the ASCII code of the keys as integer, so you can do comparisons such as:
int key = cv::waitKey(0); if (key == 'a'){ ...}
It will return -1 if the specified time interval in the function call expires without any key being pressed This function works without any problems in Debian Squeeze and Wheezy, with Qt support.
I have two linux ubuntu systems. For some reason 1 system allows to use the function reading the asci value, the other one requires me to
add & 0xff. No idea however why this happens.Hmm, I never had a different behaviour either in CentOS or Debian, as far I never used OpenCV in Ubuntu for anything serious. It is noteworthy mention that it also gives keycodes that are not ASCII for directional keys, and it aborts your program with an Qt assertion (not OpenCV error) if you press any non-ascii key from Spanish/Brazilian/French keyboards (such as "ñ","ç"). I´m not sure if this happens if compiled without Qt support, thought.
@StevenPuttemans Can you check the locales of the two machines you have? If the locale is different, that may be the answer to this puzzle.
@unxnut that did the trick. Set the locale both to US_ENG fixed the non working ASCI returns.