Emteria Android on RaspPi3 with Makibes 7" 1024x600 Screen

edited November 2017 in Screens

Hi,
I´m new with Emteria and RaspPi. My idea is to build an entertainment and OBD information system for my car. Tried CarPi already but the OBD functionalities are far away from sufficiant.
Therefore, my idea is to use Android. Due to the app Torque, all needed OBD information are shown as needed - runtime information with several gauges, OBD code information and many others.

But now please let me describe my issue:
I bought a Makibes 7" screen with 1024x600 resolution and touchscreen. I bought it based on the idea using CarPi where it is fully supported and working very well. But in Emteria I have two issues with it:
1. The resolution seems not to be the right one. I assume, it shows me only around 640 or 800xsomething.
2. The touchscreen is not in sync. It reacts to high and to much to the left as well

The screen starts fine in the upper left corner but down and right is missing around 30% is suppose.

I got the following information for the config.txt file from Makibes for Raspbian:
max_usb_current=1
hdmi_group=2
hdmi_mode=1
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0
hdmo_drive=1

How can I enter that information to the config.txt file in Emteria and how can I sync the touchscreen. Bascially, it seems to be tthat Emteria is what I´m looking for. WLAN network is showing my router, but I´m not able to enter the needed key due to the onscreen keyboard is not appearing completely.

Could you please help me out to fix my situation? What can I do to make the screen fully visible and sync the touchscreen.

Many thanks in advance and best regards,
Garfield73

Comments

  • Hi again,

    just found out that the resolution isn´t lower as the expected 1024x600. It seems to be that the res is higher. As described earlier, I cannot see the full screen - therefore it must be higher than 1024x600.

    Found the following post:
    https://forum.emteria.com/discussion/9/changing-screen-resolution#latest
    that explains which files have to be changed.

    Do I have to mount the sd card to a linux system to do that, or to use ADB somehow - read this several times in some posts.
    How can I "reach" the files?

    Is there any option to connect the RasPi to the network via LAN cable? My router spends an IP address to the MAC of the Pi but didn´t test it right now if Emteria will be reachable via network then with ssh. Is there any user/password in place that can be used to connect via ssh?

    Many thanks again,
    Garfield73

  • You can mount your sdcard in Linux and edit those files manually. Or your can use "vim" from the ADB shell. For the latter, you will need to be in root mode and remount the /boot partition to be writeable.

  • Hi kalkov,

    please apologize to bother you again.

    it seems to be that I have no success so far. Please let me show you my config.txt how it looks after my changes:

    cat config.txt
    max_usb_current=1
    hdmi_group=2
    hdmi_drive=1
    hdmi_mode=1
    hdmi_mode=87
    hdmi_cvt=1024 600 60 6 0 0 0
    hdmi_force_hotplug=1
    disable_overscan=1

    dtoverlay=vc4-kms-v3d,cma-256
    avoid_warnings=2

    dtparam=audio=on
    dtparam=i2c1=on
    dtparam=i2c_arm=on

    initial_turbo=30
    start_x=1
    kernel=u-boot.bin

    fdisk shows me the following:
    /dev/mmcblk0p1 * 2048 129023 126976 62M c W95 FAT32 (LBA)
    /dev/mmcblk0p2 129024 4323327 4194304 2G 83 Linux
    /dev/mmcblk0p3 4323328 4454399 131072 64M 83 Linux
    /dev/mmcblk0p4 4454400 62333951 57879552 27,6G 83 Linux

    I found the config.txt in p1 and I found /system in p4.
    But I cannot find the /system/build.prop file in p4. Is that something I have to create there or will the file only be there in runtime?

    In case I have to create the build.prop file myself, which lines have to write in it?

    I really appreciate your help.

    Thanks and best regards,
    Garfield73

  • Hi again,

    just created that file in system now and used the following values:

    /mnt1/system# cat build.prop
    debug.drm.mode.auto=1
    debug.drm.mode.force=1024x600
    ro.hdmi.device_type=4
    ro.opengles.version=131072
    ro.radio.noril=1
    ro.rfkilldisabled=1
    ro.sf.lcd_density=213
    wifi.interface=wlan0

    The file has the following uid:gid - 1000:1000

    But still don't have the right resolution.

    Best regards,
    Garfield73

  • You don't need to create "build.prop", it should be there from the beginning. If it isn't, try a new installation and check again.

  • Ok, will try a complete new installation now.

    Best,
    Garfield73

  • edited November 2017

    Hi kalkov,

    did a fresh installation, but had exactly the same result.
    So I did another one and did some deeper examinations what happens in the different steps.

    First, I checked the different partitions right after the upload of the installer. It seems to be that only partition1 and partition2 has any data in it. Partition3 and partition4 are completely empty.
    I did the changes to config.txt in a linux pc as given by the screen manufacturer Makibes and did the first time boot in the RaspPi3.
    It seems to be that the partition4 will be written during the first boot.

    After that, I still got the wrong resolution. Therefore, I powered off the RPi again and mounted the card in my linux pc again. As I thought, partition4 is filled up but there is still no build.prop in the "system" folder in part4.
    But then, after checking part2 again, I found that build.prop file in the root of part2.
    Basically, there is no folder "system" that was my first attempt to search for that folder in all partitions. Due to I found it in part4, I concentrated on that folder first.

    Now, after realising that the file is in part2, I did the changes to the config.txt file and changed in build.prop the force line into:

    from device/brcm/rpi3/system.prop

    #
    debug.drm.mode.auto=1
    debug.drm.mode.force=1024x600

    Wondering what "from device/brcm/rpi3/system.prop" does mean?

    After umount and putting the card back in the RPi, I still have the mess that the resolution is not showing the full screen :(.

    Moved it back in my pc and the file has been changed back to the former value 1280x720. Is there any automatism that is running during the start to identify the connected screen and using the 1280 value in case the screen is not known?

    At the end I took a normal TV and connected the RPi to it. Then I was able to realize that the white screen at the beginning is a kind of initial setup. I ran through it having the hope that this has any positive effect and prevent any changes back to the 1280 value - no.
    Moved the RPi back to the screen. Even after having a blue wallpaper now, and moved the power off icon to the upper left desktop to be able to clean shutdown the RPi, the resolution issue is still there.

    The resolution is still not showing 1024x600. Every time after a booting the RPi and shutting it down again - now with the shutdown button, the build.prop file has no longer the value 1024x600.

    Is there any kind of logfile that can be checked if there is any advice who or what is changing the value in build.prob back to the initial value? Does any script or service some changes to the file?

    One other thing I observed during the boot, it seems to be that the OS needs up to 4 tries to boot until the first time the Emteria line painting (bootscreen) appears. It looks like, that the bootstep that brings the bootscreen runs 3 times and then in the next attempt, the bootscreen appears (read something like that in other posts as well - https://forum.emteria.com/discussion/78/official-7-touchscreen#latest).
    It reaches the last step before switching over to the bootscreen (something with kernel the last message say) and than the RPi reboot. At the fourth attempt, the boot succeeds and the bootscreen appears - but the painting is in the lower right corner - due to the resolution is wrong.

    Hope that my typing isn't too long and forwards something usefull. In case you need more information of any file, please give me a note.

    Cheers,
    Garfield73

  • Hi,

    finally, I did it. I did some other changes in the config.txt file based on my CarPi experiences. For me it seems to be that the build.prop file is under OS control somehow and will be managed by it during the boot.

    The following config.txt helped me out for the resolution issue:

    cat config.txt
    hdmi_group=2
    hdmi_drive=2
    hdmi_mode=1
    hdmi_mode=87
    hdmi_cvt=1024 600 60 6 0 0 0
    hdmi_force_hotplug=1
    disable_overscan=1
    max_usb_current=1

    framebuffer_width=1024
    framebuffer_height=600

    gpu_mem=256

    dtoverlay=vc4-kms-v3d,cma-256
    avoid_warnings=2

    dtparam=audio=on
    dtparam=i2c1=on
    dtparam=i2c_arm=on

    initial_turbo=30
    start_x=1
    kernel=u-boot.bin

    Now, I'll moving forward regarding the touchscreen. After that I'll try to install some apps:
    Torgue
    Sygic Navigation

    Will keep you informed in case you want to follow my steps.

    Best regards,
    Garfield73

  • edited November 2017

    Unfortunately I have to say that the screen only had the right resolution until I did a reboot of the RPi. After that, both files config.txt and build.prod had the former configuration - hdmi_cvt=1280x720... and debug.drm.mode.force=1280x720.

    It seems to be that there must be any procedure during the boot process before the screen switches over to the bootscreen painting the Emteria sign. It might be something regarding this three time boot before it switches over, or something that will be written after the first shutdown.

    I change the values in both files and start the RPi, resolution is fine. I press shutdown or restart and start it again, and the resolution is wrong and the files are back to default... strange, very strange.

    But I think, I found a way to block this now. Restarted the RPi now more than 10 times and the resolution is still the right one.

    Kalkov, am I wrong or is the content in build.prod file static normally?. Will mean, is there any reason why that file should be changed (aside that resolution thing) in the day by day work?
    Finally, I used the chattr command to prevent also root from being able to change the file. I used chattr -a to prevent any modification of the file. With -a it is only possible to append something - it seems to be that -i is not needed.

    Maybe you have some further ideas why that whole behavior is happening. Believe me, I reinstalled the SD card nearly a dozen times yesterday. The behavior could be reproduced every time.

    Many thanks and best regards,
    Sascha

  • @Garfield73, sorry I missed this thread. It is shifted to the next page and I must have skipped it. So, if you have a working configuration for config.txt and build.prop, you can simply change the line "debug.drm.mode.auto=1" to "debug.drm.mode.auto=0" and it will stop emteria.OS from switching back.

    Short explanation:
    emteria.OS is running with many different screens. In the vast majority of cases, it correctly detects the resolution without any changes required. If you do wish to set your own configuration, just disable the automatic detection. Another way would be to use "vc4-fkms-v3d" overlay (instead of "vc4-kms-v3d"). If you do that, Android will only recognize the resolution from config.txt and adjust its resolution automatically (no need to change build.prop at all).

    I hope this helps.

  • For me, the black screen was eliminated by dropping "f" from the "vc4-fkms-v3d" line. I have an original 7 "RPi3 screen with 800x480 resolution.

  • @obero, this explains your picture quality. If you are using the official touchscreen, just install emteria.OS 0.4.4+. It will use fkms by default for full color depth.

  • Thank you for your help, but how can I get what you have recommended? emteria.OS 0.4.4+?

  • The problem with my voice is that I can not use my Hifiberry DAC + card, no sound comes out. I've tapped, there's a sound, but there's a constant high-intensity continuous sound around 1KHz. Connects to the middle of the boot and is continuous. How can I get it out?

  • With 0.4.4+ I mean any version higher than 0.4.4. For example the latest one: 0.4.6.
    We don't have Hifiberry here for testing. You have to refer to the original documentation for its configuration.

  • I think it's enough to be able to switch between Android and RPI 3 sound because RPi 3 detects Hifiberry.

  • Hi kalkov,

    please apologize to answer that late. But my last weeks were full of work and there was no time for any personal projects. Now, my holiday vacations started and there are options to catch up time.

    Many thanks for the information how to use the debug.drm.mode.auto correctly.
    After changing that one to "0" it is no longer necessary to manipulate the file attributes. Thanks for that.

    Please let me ask if the "get a full license" offer is still open? I would be happy to forward some pictures about my Entertainment and OBD Information Screen.

    Many thanks and best regards,
    Garfield73

  • edited December 2017

    @Garfield73, I'm glad it works. We still have to find a way to keep these changes across updates :confused:

    I'm not sure about the offer, but feel free to simply copy&paste your message in the corresponding thread and I'll remind @phyl to make an official statement about the current status: https://forum.emteria.com/discussion/155/get-a-free-full-license-emteria-gmbh-is-looking-for-your-use-cases#latest

  • @Garfield73 please drop me an e-mail with photos at philipp@emteria.com

  • edited December 2017

    Hi kalkov, hi phyl,

    today I made a big step forward. Due to the rotation issue stated in another topic is still not solved, I dismounted all the screen parts and glued them together in a new position. Now, the screen fits in the housing completely and I only need to buy a new 90deg USB micro adapter - I destroyed the first one during my initial tries to make it smaller. I'll send the pictures in the next minutes.

    Now, the next steps are:

    • GPS, it seems to be that the USB GPS mouse I bought is not available so far
    • Wanna try RealDash app, but that one is crashing every time I'll start it
    • If these two things are working, I will spend some time to build an own battery power supply for the RasPi to prevent to boot it every time. The battery should be loaded from the engine and provide only power for the RasPi - that the RasPi will not need the car battery. The screen will be powered from the ignition circuit.

    Best regards and all the best for the x-mas days,
    Garfield73

Sign In or Register to comment.