i'm capturing framebuffer on my android device, but the decode is not working for the correctly resolution.
I found i can get the bbp and screen resoution using:
ioctl -rl 28 /dev/graphics/fb0 17920
This command return:
return buf: f0 00 00 00 40 01 00 00 f0 00 00 00 80 02 00 00 00 00 00 00 00 00 00 00 20 00 00 00
In little-endian format i have:
The last four bytes (20) is the number of bbp 32.
The first four bytes is the screen width 0xF0 = 240
Bytes 5 to 8 is the screen height 0x0140 = 320
I tried to decode the fb (Galaxy 5) using the folowing command :
./ffmpeg -vcodec rawvideo -f rawvideo -pix_fmt rgb32 -s 240x320 -i fb0 -f image2 -vcodec png image%d.png
And i got this warning:
Invalid buffer size, packet size 40960 < expected length 307200 Error
while decoding stream #0:0: Invalid argument
and this two images:
My raw file have 655.360 bytes but the correctly value expected is 614.400 bytes using this equation:
fileSize = xres * yres * bpp/8 * numberOfFrames
fileSize = 240 * 320 * 32/8 * 2 (android use double framebuffer) =
614.400
For my surprise i change width size on ffmpeg to 256 to match 655.360 bytes and worked (kind of, there are 16 extras pxs on the right side!
I got the following images:
So my question is WHY i have to use 256 width if my screen resolution is 240. And how to discovery this magic number for others resolutions.
You should used line_length to calculate size of line.
+-------------------------+----+
| | |
| | |
|<-------- XRES --------->| | = Xres is display resolution
| | |
| | |
|<------- LINE LENGTH -------->| = Memory Size per line
| | |
| | |
+-------------------------+----+
^ ^
| |
display on screen --+ +----> This is stride
The right padding is called "stride" (stride = (line_length in pixel) - width). Many device had this stride in the framebuffer if the display resolution is not multiply of 8.
So the formula is:
fileSize = line_length * yres * numberOfFrames
Don't multiply it with bpp/8, because the line_length is memory size (not pixel size).
To retrive the line_length You should used FBIOGET_FSCREENINFO (0x4602 - 17922) rather than FBIOGET_VSCREENINFO (0x4600 - 17922) like this:
ioctl -rl 50 /dev/graphics/fb0 17922
My Galaxy Nexus return like this:
return buf: 6f 6d 61 70 66 62 00 00 00 00 00 00 00 00 00 00 00 00 a0 ac 00 00 00
01 00 00 00 00 00 00 00 00 02 00 00 00 01 00 01 00 00 00 00 00 80 0b 00 00 00 00
^_________^
My Galaxy Nexus have line_length: 2944 (0xb80).
Related
I am sending HDMI CEC command to Power on and Standby my LG LED TV 2015 make. The device is a Amlogic S922x based SBC running Android 9. The Power On commands work but the Standby commands don't. Can someone tell me what is wrong with this?
Power ON command (works):
echo 0x40 0x04 > /sys/class/cec/cmd
Power OFF command (does not work):
echo 0x40 0x36 > /sys/class/cec/cmd
Output of
echo 0x40 0x36 > /sys/class/cec/cmd && sleep 0.1 && cat /sys/class/cec/dump_reg
AO_RTI_PWR_CNTL_REG0: 0x00004200
AO_CEC_GEN_CNTL: 0x00000000
AO_CECB_CLK_CNTL_REG0: 0xd02db2dc
AO_CECB_CLK_CNTL_REG1: 0x0000a007
AO_CECB_GEN_CNTL: 0x0000710a
AO_CECB_RW_REG: 0x02010300
AO_CECB_INTR_MASKN:0x0000003f
AO_CECB_INTR_STAT: 0x00000000
CEC MODULE REGS:
CEC_CTRL = 0x03
CEC_MASK = 0x00
CEC_ADDR_L = 0x10
CEC_ADDR_H = 0x00
CEC_TX_CNT = 0x05
CEC_RX_CNT = 0x02
CEC_LOCK = 0x00
CEC_WKUPCTRL = 0x10
RX buffer: 04 83 00 e0 91 00 00 00 00 00 00 00 00 00 00 00
TX buffer: 4f 84 10 00 04 00 00 00 00 00 00 00 00 00 00 00
Try 0xF0 0x36 instead of 0x40 0x36.
Get codes from here: https://www.cec-o-matic.com/
Looks like 0x40 is when source is "playback 1". If you set the source to "unregistered" the result code for standby is 0xF0 0x36. Worked for me on Amlogic and Samsung TV.
I'm running an android app (custom) that scans for nearby Bluetooth low energy devices, and I am noticing that some devices have longer advertised packets than specifications provision for. The scanning device is a Nexus 5 running Android 6.0.
I am using the following line on a ScanResult object result.getScanRecord().getBytes(); to get the byte array
I know that the ScanRecord's byte array is actually constructed of the advertised data (mac address not included) and the scan response, so I expect 31 bytes each for a total of 62 bytes in the array. This is the size of the total array that I receive, but it looks like the advertised data makes it into the response portion of the array. The format follows the specification, where the first byte of a GAP is the length, next byte is GAP type, and next length-1 bytes is data.
But with this format, the devices in question have data fields that extend over into the response portion. Here's an example of the array in hex, with each GAP on a different line:
02 01 06 (flags)
0D FF DF 00 57 30 46 30 30 33 43 45 56 5A (manufacturer specific data)
11 07 6D 69 73 66 69 74 A6 34 4A 7D 7F 95 01(<-expected end of advertise) 00 DA 3D (UUID, 128-bit)
07 09 46 6F 73 73 69 6C (device name)
03 03 12 18 (UUID, 16-bit)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (leftover bytes)
I don't really care about the scan response data, but I am confused as to how a BLE device could send advertisement packets larger than 31 bytes if it is on 4.2 specification (I know Bluetooth 5 allows larger packets, but the manufacturer states it uses 4.2). I can also see the name of the device showing as it should, but in the response portion.
Would anyone know why this is the case here? Thanks.
Probably those devices simply don't follow the specification (which requires an entry not to cross the packet boundaries). So your device might send
02 01 06 0D FF DF 00 57 30 46 30 30 33 43 45 56 5A 11 07 6D 69 73 66 69 74 A6 34 4A 7D 7F 95
as the Advertising Data and
01 00 DA 3D 07 09 46 6F 73 73 69 6C 03 03 12 18
as the Scan Response Data. You can see for example in the HCI log if this is correct. If it is so, you should complain to the manufacturer of that BLE device.
I have a device to run (gsensor, MPU6050) with an Android system.
I can't build it directly because it does not exist with the 3.4 kernel, but I wonder if I can modify the MPU3050 driver for my device works.
I have found this readme, but I wonder if it will work ?
Edit: After half of work*, here a part of dmesg:
<7>[ 13.283019] i2c-core: driver [mpu3050] registered
<6>[ 13.283119] init: command 'insmod' r=0
<4>[ 13.312403] industrialio: module is from the staging directory, the quality is unknown, you have been warned.
<6>[ 13.315656] init: command 'insmod' r=0
<4>[ 13.320725] kfifo_buf: module is from the staging directory, the quality is unknown, you have been warned.
<6>[ 13.321687] init: command 'insmod' r=0
<4>[ 13.329837] ring_sw: module is from the staging directory, the quality is unknown, you have been warned.
<6>[ 13.330847] init: command 'insmod' r=0
<6>[ 13.354793] hub 4-0:1.0: [hub_activate 872]
<4>[ 13.392922] inv_mpu_iio: module is from the staging directory, the quality is unknown, you have been warned.
<7>[ 13.395860] i2c-core: driver [inv-mpu-iio] registered
i2ctools detect this:
# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU UU UU UU UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU UU UU UU UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
# i2cdetect -y 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU UU UU UU UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
# i2cdump -f -y 2 0x68
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 89 75 81 e1 1e 0f fb 1e fe 8d 00 a8 28 51 50 b9 ?u????????.?(QP?
10: 86 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?...............
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 ...........#....
70: 00 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 .....h..........
80: 89 75 81 e1 1e 0f fb 1e fe 8d 00 a8 28 51 50 b9 ?u????????.?(QP?
90: 86 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?...............
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 ...........#....
f0: 00 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 .....h..........
# i2cget -f -y 2 0x68
0x75
# i2cget -f -y 2 0x68
0xe1
# i2cget -f -y 2 0x68
0x0f
# i2cget -f -y 2 0x68
0x1e
# i2cget -f -y 2 0x68
0x8d
#
*Just the drivers has been compiled, the kernel hasn't been modified. The following here.
Yes, you can.
Consult the data sheets for the difference between the capabilities and registers of each device, but I believe you will find that the mpu-6050 is a superset of the mpu-3050 so extending a driver for one to accommodate the other should be a simple case of programming-by-example.
Your question as asked is borderline inappropriate here - Stackoverflow exists to provide assistance with specific problems and you have not stated any actual issue beyond wondering if it possible, to which the answer as given above is yes, provided that you do the work and learn from the resources available to you.
I have an audio recording app on android, and I've encountered a strange issue on a friend's phone.
One of the recordings did not work and throws:
E/MediaPlayer-JNI(5996): QCMediaPlayer mediaplayer NOT present
E/MediaPlayer(5996): Unable to create media player
E/com.audioRec.player.MediaPlayer(5996): setDataSourceFD failed.: status=0x80000000
E/com.audioRec.player.MediaPlayer(5996): java.io.IOException: setDataSourceFD failed.: status=0x80000000
but it is playing with success on windows media player, vlc player, etc !!!!!!!!!
Could someone take a look over the header of the "RecordingNotOk.wav" file?
Here are both recordings
For the RecordingNotOk.wav file, it sounds like the specified size of the data chunk is bigger than the file size:
00 F8 0A 00 in little endian is 718848 bytes while the whole file size is only 716844 and the actual data size available for this chunk is only 716800
This number can be found here (3rd line after 'data'):
52 49 46 46 24 F0 0A 00 57 41 56 45 66 6D 74 20 RIFF $ð?? WAVE fmt
10 00 00 00 01 00 02 00 80 3E 00 00 00 FA 00 00 ???? ???? >?? ?ú??
04 00 10 00 64 61 74 61 00 F8 0A 00 00 00 00 00 ???? data ?ø?? ????
Basically it seems that your file has been truncated. Some players might ignore this and try to play whatever is available up to the end of the file. I guess on Android it tries to read the whole file first according to the expected size hence the IOException
Based on this article, i'm trying to emulate mifare card managing APDU on android.According to the APDU receive, my application should answer the right APDU, thus simulating the mifare behaviour.
with rfidiot.py, reading a mifare card give me :
> FF CA 00 00 00
< CD EA 7D 2B 90 0
Tag ID: CDEA7D2B
ATR: 3B8F8001804F0CA000000306030001000000006A
Setting Mifare Key A: FFFFFFFFFFFF
Authenticating to sector 00 with Mifare Key A (FFFFFFFFFFFF)
> FF 82 20 00 06 FF FF FF FF FF FF
< [] 90 0
> FF 88 00 00 60 00
< [] 90 0
OK
Dumping data blocks 01 to 01:
> FF 88 00 01 60 00
< [] 90 0
> FF B0 00 01 01
< [] 6C 10
> FF B0 00 01 10
< 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90 0
01: 00000000000000000000000000000000 ................
With my app simulating the card i got a wrong comportment:
> FF CA 00 00 00
< 08 F0 82 65 90 0
Tag ID: 08F08265
ATR: 3B80800101
Setting Mifare Key A: FFFFFFFFFFFF
Authenticating to sector 00 with Mifare Key A (FFFFFFFFFFFF)
> FF 82 20 00 06 FF FF FF FF FF FF
< [] 90 0
> FF 88 00 00 60 00
< [] 90 0
OK
Dumping data blocks 01 to 01:
> FF 88 00 01 60 00
< [] 90 0
> FF B0 00 01 01
< [] 69 81
Failed: Command incompatible with file structure
An error appear on FF B0 00 01 01 APDU command. And i don't know where the 6981 APDU command comes from..
Does someone can help me on this "bug" ?
It is not possible what you are trying to do... What #NikolayElenkov has done is emulate a ISO 7816-4 compliant card. MIFARE Classic is not ISO 7816-4 compliant (it does not use APDU commands and responses for communication). In fact, it is not even ISO 14443-4 compliant: it uses proprietary encryption on top of ISO 14443-3.
The fact that the communication looks like APDUs from the reader side, is because your reader strips off all encryption before it passes the data on and wraps that data inside "virtual" APDUs. In that way, MIFARE cards can be used with software that can only deal with ISO 7816-4 compliant cards.