I have a USB keypad with 0 to 9,*,#,+,-,CALL,CALLEND keys and I am using it with an Android board.
With the default android Generic.kl file, this keypad provides proper output for each key pressed (checked in a TextBox and this application).
Scan code of these are as below as per application mentioned above,
CALL - META_SHIFT_ON | META_SHIFT_RIGHT_ON - scanCode:48 keyCode:30
KEYCODE_B
ENDCALL - META_SHIFT_ON | META_SHIFT_RIGHT_ON - scanCode:30 keyCode:29
KEYCODE_A
STAR - META_SHIFT_ON | META_SHIFT_RIGHT_ON - scanCode:9 keyCode:15
KEYCODE_8
POUND - META_SHIFT_ON | META_SHIFT_RIGHT_ON - scanCode:4 keyCode:10
KEYCODE_3
I need to remap it, and my custom .kl content is as follows,
key 2 1
key 3 2
key 4 3
key 5 4
key 6 5
key 7 6
key 8 7
key 9 8
key 10 9
key 11 0
key 12 VOLUME_DOWN
key 78 VOLUME_UP
key 30 ENDCALL
key 48 CALL
I have put it in /system/usr/keylayout/
Now with this change, when I am checking the scan code with same test application, I am getting scanCode:54 for the ENDCALL button which was previously 30.
I have following questions from this behavior,
What my understanding is of scan codes is that they are hardware specific and it will provide the same scan code every time whatever the software/host is? I mean scan code for keypad will not change? Which is not happening here.
I have also tried with adding file .kcm in /system/usr/keychars/ but with or without it the behaviour is the same. Do I need to use a .kcm file for it?
Yes, afaik scan codes are specific to firmware residing in hardware. i.e for keypad/keyboard devices scan code will be provided by hardware and they will be unique to distinguish keys.
In android, if you don't want to alter character map of your device, you don't need character map file(.kcm). Job of character map file is to map keycode to human readable character. If you don't provide .kcm file for your device it will use Generic.kcm file for character mapping.
You can also refer link 1 & 2 for more information.
Related
Many Android devices with AMOLED screens display all images with oversaturated colors by default. E.g. Samsung Galaxy phones have the "Adaptive" screen mode, which forces windows of all apps to be displayed as if they were rendered in the native screen color space, which is wider than Display-P3.
OTOH, not all such devices support EGL_EXT_gl_colorspace_display_p3, regardless of screen mode, so I can't be sure whether the device my app is running on even has a wide-gamut screen, even less determine whether this mode is the default.
So, how can I actually determine whether current screen mode is sRGB or some wide-gamut mode? I'm targeting one specific device model, Samsung Galaxy A320F/DS (AKA "A3 (2017)"), so platform-specific ways are also OK.
There are several layers where colors can be manipulated.
SurfaceFlinger. This component is common to all Android systems. One can pass a custom color matrix to it (see the source code of the handler of this request) via e.g. the following command executed as the root user:
service call SurfaceFlinger 1015 i32 1 \
f 0 f 0 f 1 f 0 \
f 0 f 1 f 0 f 0 \
f 1 f 0 f 0 f 0 \
f 0 f 0 f 0 f 1
The above example command sets a matrix that will, acting on RGBA vectors, swap red and blue channels. To reset the custom matrix to default (identity) you can simply do
service call SurfaceFlinger 1015 i32 0
You might be able to do all this from a Java/JNI app without root privileges, simply asking for some permission, I didn't research this.
mDNIe, which stands for mobile Digital Natural Image engine. It's a Samsung-specific system that acts on a lower level than SurfaceFlinger. Namely, it affects Always On Display, on which SurfaceFlinger's custom color matrix doesn't have any effect.
Current screen mode can be seen in the /sys/class/mdnie/mdnie/mode file, which appears to have the following mapping of values on Galaxy A320F/DS:
0 — AMOLED cinema (apparently aims at Display-P3),
1 — AMOLED photo (apparently aims at Adobe RGB),
2 — Basic (aims at sRGB),
3 — (don't know its purpose, but the value is accepted if written to mode)
4 — Adaptive display (the widest, apparently native screen color space).
5 — (don't know its purpose, but the value is accepted if written to mode)
Moreover, the colors are also affected by the Cool — Warm slider as well as Advanced options RGB per-channel adjustments. Changes to the former are somehow reflected in mdnie_ldu and sensorRGB files in the same directory, while the latter directly corresponds to whiteRGB file.
Also, Blue light filter feature state is reflected in the night_mode file (it also influences mdnie_ldu and sensorRGB files mentioned above).
Of the files described above, only mode is readable to a non-root user on SM-A320F/DS. On SM-G950FD (AKA "S8") nothing is accessible without root.
How to print strings on Apex3 using printer command language or SDK?
I created a library for android application to print Bitmap images on mobile thermal printers:
Apex3, 3nStar, PR3, Bixolon, Sewoo LK P30 using appropriate SDKs.
It works fine but pretty slow, every ticket of 30 cm length takes 20-40 secs to print (it depends on type of printer).
For 3nStar and Apex3 I started to do improvements to speed up a printing.
For 3nStar I developed a class which prints a header logo and formatted text with spanish characters.
(different alignments and different fonts for different parts of a ticket)
so, the ticket looks very similar as Bitmap image but a printing time is only 6 secs.
Now I have to do the same but with Apex3. And here I got stuck.
How I do it on 3nStar for strings:
I send in outputStream bytes which are commands for printer what to do.
outputStream.write(some_bytes)
First command always is
{0x1b, 0x74, 40} //Esc t ( -- [ISO8859-15 (Latin9)]
to print spanish characters.
Then, in a loop, for n strings:
I choose a font
{0x1B, 0x21, 0x00}//Esc ! 0 -- 0 is normal, 8 is bold etc.
where changing last byte I print different fonts: normal, bold, two height, two width and combined fonts.
Next I choose an alignment
{0x1b, 0x61, 48} //Esc a 48 for left, 49 for center, 50 for right
Then I convert a string in bytes using ISO_8859_1 to print spanish characters and also write in outputStream.
outputStream.write(messageString.getBytes(StandardCharsets.ISO_8859_1))
And last byte to send is
{0x0a} // Move on next line
And the above approach doesn't work with Apex3, also I failed using
http://www.old.adtech.pl/upload/Extech_Printer_Command_Language%20Rev_H_05062009.pdf
even though on page 1 of that book is written that is fit for Apex3.
I think I miss something, I start to see how to do it using some SDK feature of Android_SDK_ESC_V1.01.17.01PRO.jar
but I would prefer to do that using direct writing of bytes.
Answers I found from this
manual
Shortly differences with the approach that I described for 3nStar are:
1)Before printing set a char set
ESC F 1 //Esc t - for 3nStar
2)Set a font for text, for example
ESC K 1 3 CR //ESC F 1 - for 3nStar
3)Send a line of text with alignment
For 3nStar I can use an alignment command before sending a text, like
ESC 1 49 //Centering
But for Apex3 I have to know a line length which depends on type of font, also a length of printing string,
then I get
freeSpace = (lineLength - printingString)
and set spaces at the begining of a line (right alignment),
at the end (left alignment) or devide them (centering).
So, for both types of printers I use the same logic which differs only in 3 places.
It is simplified explanation as a real code includes several classes with hundreds lines of code.
I am trying to use Tesseract OCR on Android to read the state of a gas meter when you take a picture of it:
This is the output when I parse this image:
vb"
22% BK-G4T ||||||||I||||I|||ii\|||\
’ 64 2007
22?: 06.0"! 'm'lm Mm. 23212274 ,
v 2,0 dm’ 1
pmn 0_5 bar tm ~25°C v‘40"(1 I
1amp é 0_o1m’ sb15°cl :Sp 20°c l
'I ELSTEQ~I¢¢>>InstrogwnSs HB Z _ 18 _ 1013 . ‘
a, 069373593435- 3 I
i'23212214 Y _ w w V'
g
The idea is to extract the first 5 digits of the state of the gas meter ( 06937 on this image ).
My question is, is there a way to train Tesseract to only parse this part of the image? Absolute coordinates are not an option since every picture would be different. I am guessing the best logic would be something like: parse only white numbers on black background.
By changing the page segmentation mode (psm), tesseract 4.00.00 alpha is able to read the meter line characters correctly as 06937598-m3 apart from other characters.
The command used is:
tesseract meter.jpg output --psm 11 -l eng
--psm 11 means to recognize "Sparse text. Find as much text as possible in no particular order".
Here is the output file with showing all the ASCII control characters.
If --psm 11 works on other meter images, then you could just need to search -m3 at the end of the line to extract the who meter line characters. With that, you can get the first 5 digits right away.
Hope this help.
Rather than using a drag or swipe command in the android debug bridge or AndroidViewClient like this:
device.drag((600,800),(600,1200), 1000)
device.shell('input touchscreen swipe 600 800 600 1200 1000')
Is there some way to simulate something like the following?
1. press down on some coordinates (eventType=DOWN)
2. sleep 2 seconds (i.e. keep holding there)
3. move to some other coordinates
2. sleep 2 seconds (i.e. keep holding there)
5. release (eventType=UP)
Basically, you touch, hold there for a few seconds, drag and keep holding there for a few seconds, then release the pad.
If you take a look at AdbClient.longPress() you will see how the long press event is sent for some keys:
if name in KEY_MAP:
self.shell('sendevent %s 1 %d 1' % (dev, KEY_MAP[name]))
self.shell('sendevent %s 0 0 0' % dev)
time.sleep(duration)
self.shell('sendevent %s 1 %d 0' % (dev, KEY_MAP[name]))
self.shell('sendevent %s 0 0 0' % dev)
You can do something similar for your case.
To get an idea of what you should write, do the same set of events you mentioned and analyze them using getevent.
I am using devkit8000 which is similar to beagle board.
How to enable CONFIG_OMAP_MUX inside?
Somehow I can't find it via menuconfig. or I am looking at the wrong place?
Refer to OMAP35x Technical Reference Manual (Rev. W)
To use GPIO130 you need to make sure the register is in the correct mode for GPIO.
You can use devmem2 to peek and poke the registers.
[pg 778] Ensure bit 0 of 0x48002158 is set to 4 = Mode 4 for GPIO
Each GPIO module provides 32 dedicated general-purpose pins with input
and output capabilities; thus, the general-purpose interface supports
up to 192 (6 x 32) pins. - [pg 3358]
By that computation GPIO 130 should be in GPIO bank 5 bit 2 (plz check math).
(Assuming math is correct)
Check GPIO_OE register 0x49056034 bit 2 to ensure the direction is correct. (0=output 1=input)
Now you can set DATA_OUT at 0x4905603C bit 2 or read DATA_IN at 0x49056038 bit 2 as you need.
Once you verify that the GPIO is setup correctly and you are able to peek and poke the values you can use either set it up in your boot-loader or the kernel so it sticks at startup or you can modify it in user space using mmap or /sys/class/gpio/gpio130/.. (if exported) to get/set the values.