Hi, I've recently managed to install android x86 8.1 r5 on my Dell Latitude E6530 and got video out through HDMI to TV using LVDS-1:d via grub.
However I'm unable to get audio through HDMI.
Can anyone tell me why?
Here is what I get on terminal:
x86_64:1 $ su
x86_64:7 # cat /proc/asound/cards
0 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xf7e30000 irq 30
X86_64:/ # ls -l /dev/snd
total 0
cru-rw--- 1 system audio 116, 5 2020-08-07 00:49 controlC0
crw-rw---- 1 system audio 116, 4 2020-08-07 00:49 hwC0D0
crw-rw---- 1 system audio 116, 3 2020-08-07 00:49 pcmC0D0c
crw-rw---- 1 system audio 116, 2 2020-08-07 00:49 pcmC0D0p
crw-rw---- 1 system audio 116, 33 2020-08-07 00:49 timer
Noone has a knowledge on how to fix this?
Hi guys,
I also have same problem with "relic".
No audio on Hdmi.
My system is i3, 4Mb ram, 240 Gb ssd, ( Asus VivoPC V60).
Can anyone help us about it, please ?
Related
Can please someone say me what's the chip of FM radio that our devices use?
thanks.
Gee I just spent at least 15 minutes looking for that answer too.
Show me the ps output with BT on and I can probably tell you the family. btld or brcm_patchram_plus are components of the proprietary Broadcom BT stack which is the most common.
btipsd would be a TI device.
Just hciattach without any of the above might require checking the /init.*.rc files for the options to hciattach. Firmware files are also a clue, as is dmesg output.
Of course you might have a rarer Silicon Labs chip and lsmod might show it, or some fm device driver pseudo file in /dev/ and perhaps Si4709_driver.ko or similar somewhere.
If you have a working hcitool and bt is enabled this HCI Get Version command would show something similar to this:
adb shell hcitool cmd 4 1
< HCI Command: ogf 0x04, ocf 0x0001, plen 0
> HCI Event: 0x0e plen 12
01 01 10 00 04 00 00 04 0D 00 1F 1D
If you have a working hcitool on a Broadcom family device the following would be shown when the radio and RDS are on:
adb shell hcitool cmd 3f 15 0 1 1
< HCI Command: ogf 0x3f, ocf 0x0015, plen 3
00 01 01
> HCI Event: 0x0e plen 7
01 15 FC 00 00 01 03
And here's the equivalent on a TI device:
adb shell hcitool cmd 3f 133 20 2 0
< HCI Command: ogf 0x3f, ocf 0x0133, plen 3
20 02 00
> HCI Event: 0x0e plen 6
01 33 FD 00 00 03
Here's my output
Code:
# hcitool cm 4 1
hcitool cm 4 1
# hcitool cmd 3f 15 0 1 1
hcitool cmd 3f 15 0 1 1
< HCI Command: ogf 0x3f, ocf 0x0015, plen 3
00 01 01
Send failed: File descriptor in bad state
# hcitool cmd 3f 133 20 2 0
hcitool cmd 3f 133 20 2 0
< HCI Command: ogf 0x3f, ocf 0x0133, plen 3
20 02 00
Send failed: File descriptor in bad state
#
What does Descriptor means?
D4rKn3sSyS said:
Here's my output
Code:
# hcitool cm 4 1
hcitool cm 4 1
# hcitool cmd 3f 15 0 1 1
hcitool cmd 3f 15 0 1 1
< HCI Command: ogf 0x3f, ocf 0x0015, plen 3
00 01 01
Send failed: File descriptor in bad state
# hcitool cmd 3f 133 20 2 0
hcitool cmd 3f 133 20 2 0
< HCI Command: ogf 0x3f, ocf 0x0133, plen 3
20 02 00
Send failed: File descriptor in bad state
#
What does Descriptor means?
Click to expand...
Click to collapse
If you ran these commands with Bluetooth (BT) enabled, then in this case it means you have a proprietary BT stack.
In general: http://en.wikipedia.org/wiki/File_descriptor
mikereidis said:
If you ran these commands with Bluetooth (BT) enabled, then in this case it means you have a proprietary BT stack.
In general: http://en.wikipedia.org/wiki/File_descriptor
Click to expand...
Click to collapse
its broadcom bt. with brcm_patchram_plus you can check in se sources und platform/system/bluetooth/
here is kernel config:
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_LL=y
slade87 said:
its broadcom bt. with brcm_patchram_plus you can check in se sources und platform/system/bluetooth/
here is kernel config:
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_LL=y
Click to expand...
Click to collapse
OK, thanks much.
In that case my app should be usable on this phone in the currently experimental "HCI UART" mode, where a daemon speaks directly with the UART. It only works with BT off though, but I'm hoping to find a better HCI access method. Also need root.
I should post a new experimental version on the thread in my sig in an hour or so. One warning though; on many phones where my app tunes and gets RDS data etc, there is no audio. I'm working on "tricks" for that issue also.
mikereidis said:
OK, thanks much.
In that case my app should be usable on this phone in the currently experimental "HCI UART" mode, where a daemon speaks directly with the UART. It only works with BT off though, but I'm hoping to find a better HCI access method. Also need root.
I should post a new experimental version on the thread in my sig in an hour or so. One warning though; on many phones where my app tunes and gets RDS data etc, there is no audio. I'm working on "tricks" for that issue also.
Click to expand...
Click to collapse
thank you for your development!
Hello all,
I got a Sony Xperia P (LT22i) last christmas and I have been using a freexperia built ROM ever since. The ROM uses a Cyanogenmod 4.0.4 internally. Unfortunately my phone is often quite slow to respond to user input up to the point where it doesnt even unlock the screen when I press the button. If I use htop via adb I see the following:
Mem: 798852K used, 21644K free, 0K shrd, 17748K buff, 306296K cached
CPU: 56.3% usr 38.9% sys 2.9% nic 0.5% idle 0.0% io 0.0% irq 1.1% sirq
Load average: 5.29 5.61 5.30 4/690 6823
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
4063 4010 system S 384m 47.7 90.1 system_server
791 2 root SW 0 0.0 3.9 [kworker/0:2]
6323 4010 app_66 S 330m 41.0 3.2 net.osmand
3 2 root SW 0 0.0 0.3 [ksoftirqd/0]
1536 1 system S 62044 7.5 0.2 /system/bin/surfaceflinger
863 2 root SW 0 0.0 0.2 [mmcqd/1]
4962 4927 root R 1900 0.2 0.1 top
10 2 root SW 0 0.0 0.1 [ksoftirqd/1]
6212 2 root SW 0 0.0 0.1 [kworker/0:0]
1667 1 root S 5512 0.6 0.1 /sbin/adbd
840 2 root SW 0 0.0 0.1 [kworker/u:4]
3666 2 root SW 0 0.0 0.1 [kworker/u:5]
591 2 root SW 0 0.0 0.1 [av8100_thread]
6590 2 root SW 0 0.0 0.1 [kworker/1:2]
5130 4010 app_65 S 345m 42.8 0.0 {ockplus.android} org.adblockplus.andr
4306 4010 app_41 S 322m 40.0 0.0 {enmod.trebuchet} com.cyanogenmod.treb
4263 4010 app_46 S 318m 39.5 0.0 {e.process.gapps} com.google.process.g
4340 4010 radio S 310m 38.5 0.0 {m.android.phone} com.android.phone
5787 4010 app_64 S 303m 37.7 0.0 {android.youtube} com.google.android.y
5712 4010 system S 302m 37.6 0.0 {ndroid.settings} com.android.settings
The system_server seems to use up the entire CPU time causing my problems. Is there a way to fix the problem, if yes, who would I talk to about this?
Alternatively I would like to use another ROM. I have heard that my device has some quirks making it very hard to use most ROMs (most notably a broken audio driver?). For this reason I originally chose the freexperia builds despite the fact that that android version is not exactly up-to-date.
Is there another ROM that will work properly with my device?
Also I would like to know how to back up the relevant data: When I installed the current ROM, android wouldn't start until I reset the device and wiped the data in the process. I dislike every kind of backup that uses "the cloud" for obvious reasons. I just want to copy the data onto my laptop via USB (without using an App, free or not). I tried using "adb backup" but I am not sure which options I have to select to obtain the relevant data without having a >> 1 GB size BLOB on my laptop. Any ideas about that?
You would have more luck looking in your device specific subforum instead of general area.
http://forum.xda-developers.com/xperia-u
I have an old laptop with Wacom touch panel (Penabled). I am able to boot Remix OS fine but touch isn't working.
How to make touchscreen work?
Edit: Fixed by myself
View post #6 link: http://forum.xda-developers.com/showpost.php?p=65159778&postcount=6
The hardware must be unsupported.
TheBasterd said:
The hardware must be unsupported.
Click to expand...
Click to collapse
Nevermind, I fixed it myself
Care to share with the rest of us in case this issue comes up more often?
I would also be happy to know how to make a Wacom digitizer work on Remix OS as I'm looking into getting a Lenovo X61t to use with Remix OS.
YassinTP said:
I would also be happy to know how to make a Wacom digitizer work on Remix OS as I'm looking into getting a Lenovo X61t to use with Remix OS.
Click to expand...
Click to collapse
My laptop (Fujitsu T730) has Wacom digitizer with both touch input and pen. Using my method only touchscreen works (pen doesn't but I don't care )
You need to create live usb pendrive from official Android-X86 4.4 r4, run it live (without install) and copy from it inputattach file inside system/bin folder to Remix OS system/bin folder (you need rooted Remix OS for this) and set correct permissions.
Download from Play Store Terminal Emulator for Android and run:
su
inputattach --w8001 /dev/ttyS0 &
And touchscreen works
I have no idea why this file is missing in Remix OS while it is present in Android-X86 (Remix is based on Android-X86 after all)
It would be great if Remix developers could include it in next releases because as it is now you have to copy it every time you upgrade os.
Thank you very much!
Only thing is, the convertible I'm planning on buying only has a pen guess I'll just have to try if I get it working.
This is no working on my HP 2760p.
jarek3460 said:
This is no working on my HP 2760p.
Click to expand...
Click to collapse
I also tested it on HP 2760p. And it was working fine. I no longer use Remix OS so I can't confirm if this works on recent rom versions.
Remember that after copying file you have to set correct file permissions using any root capable file browser. (Try setting it to: rwxrwxrwx to be sure it works )
jarek3460 said:
This is no working on my HP 2760p.
Click to expand...
Click to collapse
were you able to ever get this working? I have a 2740p as well with only pen support
Rafostar said:
My laptop (Fujitsu T730) has Wacom digitizer with both touch input and pen. Using my method only touchscreen works (pen doesn't but I don't care )
You need to create live usb pendrive from official Android-X86 4.4 r4, run it live (without install) and copy from it inputattach file inside system/bin folder to Remix OS system/bin folder (you need rooted Remix OS for this) and set correct permissions.
Download from Play Store Terminal Emulator for Android and run:
su
inputattach --w8001 /dev/ttyS0 &
And touchscreen works
I have no idea why this file is missing in Remix OS while it is present in Android-X86 (Remix is based on Android-X86 after all)
It would be great if Remix developers could include it in next releases because as it is now you have to copy it every time you upgrade os.
Click to expand...
Click to collapse
I tried X86 Marshmellow and the Nought Beta versions, but touch is not working on them.
It is still working on Ubuntu Live and Debian. I ran lsusb and lsmod on them and got this result.
Code:
[email protected]:/home/ubuntu# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 009: ID 0bda:5830 Realtek Semiconductor Corp.
Bus 001 Device 007: ID 0bda:b720 Realtek Semiconductor Corp.
Bus 001 Device 005: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 003: ID 0bda:5830 Realtek Semiconductor Corp.
Bus 001 Device 008: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
Bus 001 Device 006: ID 04d9:e200 Holtek Semiconductor, Inc.
Bus 001 Device 004: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Code:
[email protected]:/home/ubuntu# lsmod
Module Size Used by
rfcomm 69632 2
bnep 20480 2
joydev 20480 0
rtsx_usb_ms 20480 0
memstick 20480 1 rtsx_usb_ms
intel_rapl 20480 0
x86_pkg_temp_thermal 16384 0
intel_powerclamp 16384 0
coretemp 16384 0
hid_multitouch 20480 0
kvm_intel 172032 0
kvm 536576 1 kvm_intel
irqbypass 16384 1 kvm
crct10dif_pclmul 16384 0
crc32_pclmul 16384 0
aesni_intel 167936 0
aes_x86_64 20480 1 aesni_intel
lrw 16384 1 aesni_intel
gf128mul 16384 1 lrw
btusb 45056 0
uvcvideo 90112 0
videobuf2_vmalloc 16384 1 uvcvideo
videobuf2_memops 16384 1 videobuf2_vmalloc
videobuf2_v4l2 28672 1 uvcvideo
glue_helper 16384 1 aesni_intel
btrtl 16384 1 btusb
ablk_helper 16384 1 aesni_intel
btbcm 16384 1 btusb
btintel 16384 1 btusb
cryptd 20480 2 aesni_intel,ablk_helper
bluetooth 520192 29 bnep,btbcm,btrtl,btusb,rfcomm,btintel
videobuf2_core 36864 2 uvcvideo,videobuf2_v4l2
v4l2_common 16384 1 videobuf2_v4l2
serio_raw 16384 0
videodev 176128 4 uvcvideo,v4l2_common,videobuf2_core,videobuf2_v4l2
input_leds 16384 0
media 24576 2 uvcvideo,videodev
intel_pch_thermal 16384 0
snd_hda_codec_realtek 86016 1
snd_hda_codec_hdmi 53248 1
snd_hda_codec_generic 77824 1 snd_hda_codec_realtek
snd_soc_rt5640 114688 0
snd_hda_intel 36864 5
snd_soc_ssm4567 16384 0
snd_soc_rl6231 16384 1 snd_soc_rt5640
snd_hda_codec 135168 4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel
snd_soc_core 212992 2 snd_soc_rt5640,snd_soc_ssm4567
snd_hda_core 73728 5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
snd_hwdep 16384 1 snd_hda_codec
snd_seq_midi 16384 0
snd_seq_midi_event 16384 1 snd_seq_midi
snd_compress 20480 1 snd_soc_core
ac97_bus 16384 1 snd_soc_core
snd_rawmidi 32768 1 snd_seq_midi
snd_pcm_dmaengine 16384 1 snd_soc_core
snd_seq 69632 2 snd_seq_midi_event,snd_seq_midi
snd_pcm 106496 7 snd_soc_rt5640,snd_soc_core,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_pcm_dmaengine,snd_hda_core
int3403_thermal 16384 0
mei_me 36864 0
snd_seq_device 16384 3 snd_seq,snd_rawmidi,snd_seq_midi
mei 98304 1 mei_me
kxcjk_1013 20480 0
elan_i2c 36864 0
snd_timer 32768 2 snd_pcm,snd_seq
industrialio_triggered_buffer 16384 1 kxcjk_1013
dw_dmac 16384 0
lpc_ich 24576 0
8250_dw 16384 0
snd 81920 23 snd_hda_codec_realtek,snd_soc_core,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_compress
dw_dmac_core 24576 1 dw_dmac
int3400_thermal 16384 0
int3402_thermal 16384 0
processor_thermal_device 16384 0
acpi_als 16384 0
intel_soc_dts_iosf 16384 1 processor_thermal_device
acpi_thermal_rel 16384 1 int3400_thermal
int340x_thermal_zone 16384 3 int3402_thermal,processor_thermal_device,int3403_thermal
kfifo_buf 16384 2 industrialio_triggered_buffer,acpi_als
snd_soc_sst_acpi 16384 0
soundcore 16384 1 snd
i2c_designware_platform 16384 0
i2c_designware_core 20480 1 i2c_designware_platform
spi_pxa2xx_platform 24576 0
industrialio 57344 4 industrialio_triggered_buffer,acpi_als,kxcjk_1013,kfifo_buf
mac_hid 16384 0
acpi_pad 20480 0
parport_pc 32768 0
ppdev 20480 0
lp 20480 0
parport 49152 3 lp,ppdev,parport_pc
autofs4 40960 2
overlay 49152 1
nls_iso8859_1 16384 3
dm_mirror 24576 0
dm_region_hash 24576 1 dm_mirror
dm_log 20480 2 dm_region_hash,dm_mirror
mmc_block 36864 2
hid_generic 16384 0
usbhid 49152 0
rtsx_usb_sdmmc 28672 0
rtsx_usb 24576 2 rtsx_usb_sdmmc,rtsx_usb_ms
uas 24576 0
usb_storage 69632 4 uas
i915 1208320 5
i2c_algo_bit 16384 1 i915
drm_kms_helper 147456 1 i915
syscopyarea 16384 1 drm_kms_helper
sysfillrect 16384 1 drm_kms_helper
ahci 36864 0
sysimgblt 16384 1 drm_kms_helper
libahci 32768 1 ahci
fb_sys_fops 16384 1 drm_kms_helper
drm 360448 6 i915,drm_kms_helper
video 40960 1 i915
i2c_hid 20480 0
hid 118784 4 i2c_hid,hid_multitouch,hid_generic,usbhid
sdhci_acpi 16384 0
sdhci 45056 1 sdhci_acpi
fjes 28672 0
Rafostar said:
I also tested it on HP 2760p. And it was working fine. I no longer use Remix OS so I can't confirm if this works on recent rom versions.
Remember that after copying file you have to set correct file permissions using any root capable file browser. (Try setting it to: rwxrwxrwx to be sure it works )
Click to expand...
Click to collapse
Thank you so much Rafostar this helped getting my touch screen working on my hp 2740p
although it worked after the command was inputted. it failed to work after reboot
to fix this I needed to edit system/etc/init.sh
edit init.sh function init_misc
add command to line 18
inputattach --w8001 /dev/ttyS0 &
Redesterdragon said:
Thank you so much Rafostar this helped getting my touch screen working on my hp 2740p
although it worked after the command was inputted. it failed to work after reboot
to fix this I needed to edit system/etc/init.sh
edit init.sh function init_misc
add command to line 18
inputattach --w8001 /dev/ttyS0 &
Click to expand...
Click to collapse
I forgot to mention that you have to do this every time after reboot or create/add it to a startup script like you did
Rafostar said:
I forgot to mention that you have to do this every time after reboot or create/add it to a startup script like you did
Click to expand...
Click to collapse
I noticed that after falling asleep the touchscreen stops working again till reboot or manually entering the command within the command line
Rafostar said:
I forgot to mention that you have to do this every time after reboot or create/add it to a startup script like you did
Click to expand...
Click to collapse
what would I do to activate inputattach during wake?
Redesterdragon said:
what would I do to activate inputattach during wake?
Click to expand...
Click to collapse
I found one method of disabling sleep using a wake_lock command by placing it within the init.sh file under the function_misc section line 19
echo lock_me > /sys/power/wake_lock
this will dim the screen but not turn off the CPU so the digitizer will remain active now.
Please let me know if this might cause any other unfavorable issues.
In my case, x86 Oreo rc1 on a Thomson THBK1.10 64DHKP, a cute old thing I experimented my very first dual-boot on. Like many, I'm not getting any sound, and that's after trying a whole bunch of fixes. Here's a sample of what the terminal has to say:
x86_64:/ $ alsa_ctl init
alsa_ctl: init:1744: No soundcards found...
19|x86_64:/ $ alsa_aplay -l
aplay: device_list:242: no soundcards found...
x86_64:/ $ cat proc/asound/cards
0 [bytcrrt5640 ]: bytcr-rt5640 - bytcr-rt5640
bytcr-rt5640
1 [IntelHdmiLpeAud]: IntelHdmiLpeAudiIntelHdmiLpeAudio - IntelHdmiLpeAudio
x86_64:/ $ su
x86_64:/ # alsa_aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: bytcrrt5640 [bytcr-rt5640], device 0: Baytrail Audio (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: bytcrrt5640 [bytcr-rt5640], device 1: Deep-Buffer Audio (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: IntelHdmiLpeAud [IntelHdmiLpeAudio], device 0: IntelHdmiLpeAudio [IntelHdmiLpeAudio]
Subdevices: 1/1
Subdevice #0: subdevice #0
x86_64:/ # alsa_ctl init
Found hardware: "bytcr-rt5640" "" "" "" ""
Hardware is initialized using a generic method
99|x86_64:/ # alsa_aplay sauce.wav
sauce.wav: No such file or directory
1|x86_64:/ # alsa_aplay storage/emulated/0/download/ce.mp3
Playing raw data 'storage/emulated/0/download/ce.mp3' : Unsigned 8 bit, Rate 8000 Hz, Mono
aplay: set_params:1125: Unable to install hw params:
ACCESS: RW_INTERLEAVED
FORMAT: U8
SUBFORMAT: STD
SAMPLE_BITS: 8
FRAME_BITS: 8
CHANNELS: 1
RATE: 8000
PERIOD_TIME: 125000
PERIOD_SIZE: 1000
PERIOD_BYTES: 1000
PERIODS: 4
BUFFER_TIME: 500000
BUFFER_SIZE: 4000
BUFFER_BYTES: 4000
TICK_TIME: 0
1|x86_64:/ #
What's strange is that my hardware does seem to be detected, but only by apps with SU privileges; trying anything alsa-related nets me no cards until I switch the terminal to SU. Yet cat and ls do detect properly. Like I said, every one of the online fixes I tried netted me nothing, and actually demanding a sound be manually played throws another error, to the point I'm not even sure Oreo is even supposed to have functional sound. What keeps me sticking to it is that the issue shows up in earlier versions, so I half-wishfully assumed the issue might be elsewhere.
Somebody help this idiot.
My setup:
- Windows 10
- MEmu emulator (running on W10)
I need to send the screen of the Android device in MEmu in realtime to Windows 10, because I need full opencv support for AI processing. I would need low latency and > 5 fps.
Right now I'm exploring 2 ways:
1. Using adb and creating something like a socket interface (like github/DeviceFarmer/minicap can't post url yet, sorry)
2. Using a script to capture the MEmu window in Windows: this approach could be more challenging because I would need to be able to capture the screen even when the window is on the background
I tried out the minicap tool, but I couldn't get it working on Windows.
Do you have any idea of how can I solve this problem? I'm new to Android development and adb so I don't know how can I face this...
MEmu App Player ( short: MEmu ) is a Windows app ( based on Oracle VirtualBox VM ) - hence it is presented on Windows computer in a window as that is case with all Windows apps - what internally presents in a child window the output of the emulated Android device As you can see you have to do it with 2 windows in sense of Windows OS.
This child window basically can get accessed via ADB, means its screen contents can get captured via ADB command. Hereby the emulated device’s standard screen resolution is used, the video is encoded at a bitrate of 4Mbps, and the maximum screen recording time is limited to 180 seconds.
Take note that MEmu comes with a screen recorder tool implemented that allows you to capture contents of its child window, too. Videos taken via this tool get stored in a shared folder on Windows computer.
jwoegerbauer said:
MEmu App Player ( short: MEmu ) is a Windows app ( based on Oracle VirtualBox VM ) - hence it is presented on Windows computer in a window as that is case with all Windows apps - what internally presents in a child window the output of the emulated Android device As you can see you have to do it with 2 windows in sense of Windows OS.
This child window basically can get accessed via ADB, means its screen contents can get captured via ADB command. Hereby the emulated device’s standard screen resolution is used, the video is encoded at a bitrate of 4Mbps, and the maximum screen recording time is limited to 180 seconds.
Take note that MEmu comes with a screen recorder tool implemented that allows you to capture contents of its child window, too. Videos taken via this tool get stored in a shared folder on Windows computer.
Click to expand...
Click to collapse
Thank you for your response. I know about the screen recorder tool, but the problem is that I'm trying to create an AI that can play some games in realtime. In order to do this, I will need access to the screen images in realtime without human interaction.
The best option I think it would be using adb, because it would allow to capture and stream the screen images natively. The alternative would be to capture the window image of the MEmu app in Windows, but as you said I will have to capture from 2 windows, and this could be a problem (I'm not an expert in this kind of things ).
Do you know if is possible to create a socket between adb/MEmu and Windows to stream the screen? Also I have problems because it doesn't exist /dev/graphics/fb0 as they say in stackoverflow[dot]com/questions/13984017/how-to-capture-the-screen-as-fast-as-possible-through-adb
Thank you in advance!
Android's framebuffer /dev/graphics/fb0 exists on all Android devices. Only its format depends on Android version.
Code:
adb devices
adb shell "cat /dev/graphics/fb0 > /data/local/fbcp_temp"
adb pull /data/local/fbcp_temp C:\fbcp_temp
jwoegerbauer said:
Android's framebuffer /dev/graphics/fb0 exists on all Android devices. Only its format depends on Android version.
Code:
adb devices
adb shell "cat /dev/graphics/fb0 > /data/local/fbcp_temp"
adb pull /data/local/fbcp_temp C:\fbcp_temp
Click to expand...
Click to collapse
Are you sure? I am in Android 7.1 and when I list the devices I get this:
Code:
(base) PS C:\Users\iagoGR> adb shell ls -a /dev
.coldboot_done
0:0:0:0
1:0:0:0
__properties__
alarm
android_adb
ashmem
binder
block
bus
com.thirdparty.superuser.daemon
console
cpu0
cpu1
cpu2
cpu3
cpu_dma_latency
cpuctl
device-mapper
fscklogs
full
fuse
hidraw0
input
kmsg
log
loop-control
mem
memcg
memory_bandwidth
msr0
msr1
msr2
msr3
network_latency
network_throughput
null
port
ptmx
pts
random
rfkill
rtc0
sg0
sg1
snd
socket
tty
tty0
tty1
tty10
tty11
tty12
tty13
tty14
tty15
tty16
tty17
tty18
tty19
tty2
tty20
tty21
tty22
tty23
tty24
tty25
tty26
tty27
tty28
tty29
tty3
tty30
tty31
tty32
tty33
tty34
tty35
tty36
tty37
tty38
tty39
tty4
tty40
tty41
tty42
tty43
tty44
tty45
tty46
tty47
tty48
tty49
tty5
tty50
tty51
tty52
tty53
tty54
tty55
tty56
tty57
tty58
tty59
tty6
tty60
tty61
tty62
tty63
tty7
tty8
tty9
ttyS0
ttyS1
ttyS10
ttyS11
ttyS12
ttyS13
ttyS14
ttyS15
ttyS16
ttyS17
ttyS18
ttyS19
ttyS2
ttyS20
ttyS3
ttyS4
ttyS5
tun
uinput
urandom
vcs
vcs1
vcsa
vcsa1
vga_arbiter
vhci
zero
It looks like in MEmu there is not framebuffer? Could that be possible? Or maybe the device got renamed... I couldn't know.
igonro said:
Are you sure?
It looks like in MEmu there is not framebuffer? Could that be possible? Or maybe the device got renamed... I couldn't know.
Click to expand...
Click to collapse
1. I have stopped using MEmu some time ago, because it's a Chinese product ... Hence can't verify your statement.
2. Because MEmu is an emulator - it has neither a CPU nor a GPU nor an APU - it may be that a framebuffer doesn't exist at all in its Android.
IIRC in a MEmu instance ( read: Oracle VirtualBox VM ) a synthetic VGA video card is used, the framebuffer there simply is a VGA buffer ( VESA BIOS ). How to access it programmatically is beyond my knowledge, in any case not by means of ADB.
FYI: I no longer participate this thread, because your issue is for me without any interest. Thanks for your understanding.