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.
Related
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
My Galaxy 5 has strange behaviour when i'm emulate a card on the ACR122U.
I think the problem occured when i ran an Android update. When the application isn't on the foreground my intent filters doesn't catch the tag anymore because the emulated tag is seen as a JIS 6319-4 instead of a ISO/IEC 14443-4 tag.
The sequence i get when the application isn't on the foreground OR is on the foreground and running in foregroundDispatch:
TgInitAsTarget
> FF 00 00 00 27 D4 8C 04 04 00 01 23 45 20 000000000000000000000000000000000000000000000000000000000000
< D5 8D 08 E0 80 90 00
TgGetData
> FF 00 00 00 02 D4 86
Target has been released error
< D5 87 29 90 00
I loop this 5 times, but none of the TgInitAsTarget will work. When i'm using enableReaderMode (without NDEF skip) i get the correct sequence:
...
> FF 00 00 00 02 D4 86 //TgGetData
< D5 87 00 00 A4 04 00 07 D2 76 00 00 85 01 01 00 9000 //SELECT command
> FF 00 00 00 05 D4 8E 02 6A 82 //file or application not found
< D5 8F 00 90 00 //Ack
> FF 00 00 00 02 D4 86 //TgGetData
< D5 87 00 00 A4 04 00 07 D2 76 00 00 85 01 00 90 00 //SELECT command
> FF 00 00 00 05 D4 8E 02 6A 82 //file or application not found
< D5 8F 00 90 00 //Ack
> FF 00 00 00 02 D4 86 //TgGetData
< D5 87 00 00 A4 04 00 07 D2 76 00 00 85 01 00 90 00 //SELECT command
> FF 00 00 00 05 D4 8E 02 6A 82 //file or application not found
< D5 8F 00 90 00 //Ack
TgGetData
> FF 00 00 00 02 D4 86
//Recieving data
Question 1
Why does Android send nothing back when the application isn't on the foreground or with enableForegroundDispatch? It's very weird because it was always working, but it looks like the update changed the behaviour of NFC.
Question 2
Is it normal that the behaviour of enableReaderMode (without NDEF skip) is different from the behaviour of enableForegroundDispatch?
Note that reader-moder mode is enabled with the following command:
nfcAdapter.enableReaderMode(this, this, NfcAdapter.FLAG_READER_NFC_A, null);
Regarding the ACR122U in host card emulation mode being detected as FeliCa (JIS X 6319-4) rather than ISO-DEP (ISO/IEC 14443-4):
This seems to be a known issue with the PN532 NFC controller. So far I did not find any solution to this. That's the same problem that you already discovered in this question of yours.
Regarding question 1: Why does Android send nothing back when the application isn't on the foreground or with enableForegroundDispatch?
Well, as you already found out, the Android device shows that it detects the emulated card as FeliCa. The response to the tgInitAsTarget command (D5 8D 08 E0 80 90 00) indicates, however, that the PN532 was activated as ISO-DEP though. Consequently, it seems that the Android device initiated the communication with the emulated ISO-DEP card but must have immediately dropped it without ever sending command frames (hence you receive the error in response to the tgGetData command). Instead, the Android device must have detected (and possibly talked to) the emulated FeliCa (actually NFCIP-1) card (which relates to the problem in the first part of my answer).
As this was working before, the update must have introduced some changes to the polling/peer-discovery algorithm of your Android device.
Regarding question 2: Is it normal that the behaviour of enableReaderMode (without NDEF skip) is different from the behaviour of enableForegroundDispatch?
That depends on what you consider "normal behavior". As you enabled Android's reader-mode with the command
nfcAdapter.enableReaderMode(this, this, NfcAdapter.FLAG_READER_NFC_A, null);
you explicitly instruct Android to behave differently than with the default tag/peer discovery mechanism (that's used with enableForegroundDispatch and the normal tag dispatch system).
The default polling will try to discover all different tag technologies (NfcA, NfcB, NfcF (fast), NfcF (slow), NfcV (possible with multiple modes), NFCIP-1 active mode, NfcBarcode; usually not in this order), hence it can discover the ACR122U in FeliCa/NFC-DEP mode.
With your enableReaderMode command, you explicitly instruct Android to only poll for NfcA. Hence, your device will properly activate the ACR122U in ISO-DEP mode and, consequently, it will start the NDEF discovery procedure.
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.
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).