DietPi-Software | Chromium: Allow to use app mode instead of kiosk mode

Created on 26 Jun 2019  ยท  42Comments  ยท  Source: MichaIng/DietPi

  • DietPi version - v6.24.1
  • Distro version - stretch
  • Kernel version - 4.19.42-v7+
  • SBC device - RPi 3 Model B+
  • Power supply used - 5.1v 2a
  • SDcard used - 32gb Samsung evo plus

  • Software title:
    /DietPi/dietpi/dietpi-autostart
    /var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh

Steps to reproduce

1) Enter a valid URL
2) Save autostart
3) reboot DietPi
4) watch web page load fine
5) pull power cord on device
6) plug power back in
7) watch the warning on the widow pop up when the page loads

Expected behavior

Should not have warnings pop up on a Kiosk device.
User may not have a mouse to click the warning away.

Suggest changing --homepage to --app
/var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh
# - Add URL for first run: URL=$(grep -m1 '^[[:blank:]]*SOFTWARE_CHROMIUM_AUTOSTART_URL=' /DietPi/dietpi.txt | sed 's/^[^=]*=//') CHROMIUM_OPTS+=" --app $URL"

Tested and running fine in my environment.

Feature Request Via Forum

Most helpful comment

NOW WOULD YA LOOK AT THAT!!!

yepyep

Auto detecting resolution :)

All 42 comments

@meeki007
Many thanks for your report and suggestion.
--app mode does not show error/warning prompts? Would be great if those were logged instead to log file/syslog or similar, in case some more important hints/errors occur.

Note to self: https://peter.sh/experiments/chromium-command-line-switches/

Well I'd love to contrib to this but I have no Idea where to find /var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh on the dev branch.

is chromium-autostart.sh generated by a scrip somewhere?

I have the Dev Branch forked. standing by for direction.

--app mode does not show error/warning prompts? Would be great if those were logged instead to log file/syslog or similar, in case some more important hints/errors occur.

It does not show the prompt as it is running in app mode.

--app: Specifies that the extension-app with the specified id should be launched according to its configuration.

@meeki007
Here it is created: https://github.com/MichaIng/DietPi/blob/dev/dietpi/dietpi-software#L11344
Let me do a quick test on x86_64.

Okay, first I was thinking, that without --homepage new tabs (ctrl+t) might not show the defined homepage anymore, but actually this was never the case. Actually I could not find any influence of the --homepage at all. Using it as --homepage=https://dietpi.com does not work, the URL always needs to be added as single argument to be opened, at least in kiosk mode.

--app=https://dietpi.com opens indeed this URL in a different "Window". If you press ctrl+t, a new window opens with address bar, so no kiosk mode anymore. Looks like kiosk mode indeed requires the URL as separate argument to be associated, so again I don't see --homepage having any effect here.

Now trying to replicate the error prompt:

  • With --homepage: confirmed
  • Without --homepage: confirmed
  • With --app independently from URL: still error prompts
  • With --app $URL: ๐Ÿˆด still error prompts

@meeki007
Hmm, on my tests the error is not solved by switching from --homepage to --app. Actually I am wondering if --app alone does even have any effect.

Testing --app=$URL: ๐Ÿˆฏ๏ธ Jep this works then. Can you try to replicate that the = is required?

  • Also I see the mentioned difference here that ctrl+t with this opens a tab with address bar.

Testing --app=$URL $URL to associate the URL to both, as argument to --app and as usual URL to open (in kiosk mode).

  • Same as above.

Testing with: --noerrdialogs: ๐Ÿˆด Does not solve it, as it is no error prompt, just a hint to restore last session.

Btw found the request to automatically disable session prompt in kiosk mode: https://bugs.chromium.org/p/chromium/issues/detail?id=438755

Okay it seems that when using the app mode, this mostly overrides the kiosk mode. As those have different behaviours, I'm not gonna implement this as default for now.
Other approaches to skip the session restore prompt: https://superuser.com/questions/237608/how-to-hide-chrome-warning-after-crash

So app mode and kiosk mode are two different things. Changing the mode will make users face different behaviour suddenly.
Only thing we could do is adding another setting to switch between kiosk mode and app mode. But I would delay this to v6.26, together with an option to hide mouse, completely or auto show/hide based on movement. This then allows some more flexibility all together, depending on user purpose, attached input devices and such.

OK I now see what made the error dialog disappear. I did not have to use any tricks so I looked at all my switches im using.
I'm running it with --incognito

The combination needed to get no errordialog is --incognito --kiosk

I just noticed it in my current line.
CHROMIUM_OPTS="--kiosk --test-type --window-size=$RES_X,$RES_Y --incognito --disable-infobars --start-fullscreen --start-maximized --window-position=0,0"

sorry my mistake.

@meeki007
Ah jep I also found --incognito as a workaround, however this implies many other unwanted things, e.g. no cache.

Been in Java script land for the last 2 years. Build some crazy stuff in BASH for lighthouse-puppy-linux years ago. Give me 6hrs im enjoying the bash challenge. Let me write in some checks and a user box for adding command-line-switches with a recommended input and change at your own risk thing warning.

Then you can clean up my bash if needed.

@meeki007
You're welcome to do so ๐Ÿ˜ƒ. We could add this to dietpi-autostart, so that when selecting Chromium autostart, this menu pops up to do some choices. The homepage URL can then be merged, as well as screen resolution.

Oh the screen resolution thing is on my mind I was going to ask you later but might as well now.

Issue - Build kiosk on a test rig with a 1280 x 720 screen installing dietpi
get it working right with the page loading.
then make an ISO of the build.
burn iso to new SD card.
Plug SD card in unit at work that is going to display the kiosk (a web cam of the front gate for the facility)
WRONG RESOLUTION!!!! the screen in the reception office is 1920x1080 !!!!!!!!!!!!
Its grabbing its old stored value from dietpi.txt
SOFTWARE_CHROMIUM_RES_X=1280
SOFTWARE_CHROMIUM_RES_Y=720

so i had to fix that by hand as well

it would save me some time to know where and what is writing them values to dietpi.txt

Just having fun learning the G_WHIP_MENU system ATM

@meeki007

it would save me some time to know where and what is writing them values to dietpi.txt

This is not automatically changed, besides on RPi when changing the resolution: https://github.com/MichaIng/DietPi/blob/dev/dietpi/dietpi-config#L979-L980

  • This should be added to all devices where dietpi-config allows to change the resolution to a defined XY value.

Sadly there is no generic way to estimate the current screen resolution, otherwise we would have automated that.
For this reason the dietpi.txt settings ๐Ÿ˜‰.
Not sure if there is a way to estimate correct resolution chromium internally, but by default with --kiosk full screen and maximised it opens with wrong resolution (black borders and/or parts outside the screen).

Auto detecting the screen resolution using methods to pull data from hdmi
well I i dealt with this before on my own kiosk build 2 years ago.
This will work for the PI i'm sure. Might be able to use it for all hdmi devices that dietpi supports.

tvservice -d edid
edidparser edid

So......
RES_X=$(edidparser edid | grep -m1 'preferred mode' | cut -d 'x' -f1 | awk '{print $NF}')
RES_Y=$(edidparser edid | grep -m1 'preferred mode' | cut -d 'x' -f2 | awk '{print $1}' | sed 's/[^0-9]*//g')

ummmm i think I broke some brains eh?

installing fresh version of dietpi on:
rasp pi, tinker board, virtual box now.

Putting chrome on hold as i may have found a solution for detecting screen resolution or ignoring it if no hdmi data can be pulled.

This is fun.

@meeki007
tvservice exists on RPi only.
edidparser is this one? https://github.com/anoopengineer/edidparser

  • Written in Go, so I guess requires Go as runtime library as well? Well I'm not keen to add this overhead just to save users from this tiny dietpi.txt entry change ๐Ÿ˜‰.
    EDIT: Ah present on RPi as well:
2019-06-27 22:06:39 root@micha:/tmp# which edidparser
/usr/bin/edidparser
2019-06-27 22:06:44 root@micha:/tmp# dpkg -S /usr/bin/edidparser
libraspberrypi-bin: /usr/bin/edidparser

Found: https://packages.debian.org/stretch/edid-decode

  • Tiny and no dependencies.
  • But requires a specific EDID file as input and at least virtual machine monitor does not provide any /sys/class/drm at all ๐Ÿค”.

Correct :)
tvservice
edidparser
are PI spacific

However I'm compiling this >>> http://www.polypux.org/projects/read-edid/
right now on my x86 box. It looks like it might work as a solution.

Easy-er doc to read for it http://manpages.ubuntu.com/manpages/trusty/man1/get-edid.1.html

Okay so on RPi we can do auto detection and use the dietpi.txt entries as fallback.
On other devices yeah there are 3rd party tools available that we might install together with Chromium to allow auto detection. Debian specific pages:

Perhaps do this when having dietpi.txt entries set to "auto" but still allow to set custom resolution? Although why would someone want to have Chromium not fill the full screen... ๐Ÿ˜„

Perhaps do this when having dietpi.txt entries set to "auto" but still allow to set custom resolution? Although why would someone want to have Chromium not fill the full screen

ummm I had to this once.
Multiviewer
https://www.amazon.com/SPLITMUX%C2%AE-Screen-Multiviewer-Real-Time-Display/dp/B00VQH8DB4
you can put multiple video sources out to one monitor.
So dude has 4 PI's and a Multiviewer ..... he will need ability to set custom resolution.

Auto Detection PI +1 but..... check the config.txt for user set resolution as many do
Other Device = try to detect else fall back to user input resolution

Always have box with resolution detected or user set displayed with the ability to change it

hmmm

So No point on us both writing BASH at the same time on the same thing. .......
You are the de facto boss :) give me a list of things you want me working on and ill start sending push from my fork to you when they are done :)

its about dang time i contributed to DietPI got 30+ units running it ATM in a industrial refrigeration and food warehouse. Running temp, pressure, nitro sensors, light poles, camera motion sensors work with node-red to alarm system so if wind not person triggering door sends video etc.

Diet pi is my goto

Kinda a heavy user of the dietpi :)

@meeki007

You are the de facto boss :) give me a list of things you want me working on and ill start sending push from my fork to you when they are done :)

I would start working/helping on this (coding way) for v6.26 and am just collecting infos/ideas for now.
If you are in mood, I would appreciate if you do a start, also as you already had great ideas and obviously more experience with resolution estimation ๐Ÿ™‚. I will assist with info where required (about DietPi/G_WHIP or whatever you need).

Auto Detection PI +1 but..... check the config.txt for user set resolution as many do
Other Device = try to detect else fall back to user input resolution

Yeah reasonable to always have the dietpi.txt values as fallback if auto detection fails, e.g. binary not available or no valid integers were returned (after mawk scraping).

Sound's Good:

This may take some time as I'm going about learning your code the way it will stick in my brain.
Not asking you questions like How the Device model is defined lead's me through 4 files that end up pointing to my goal of RPi

Then I put it in my notes for building the code.


//Get Hardware Model 
from $G_HW_MODEL from $FP_G_HW_MODEL_INDENTIFIER
see https://github.com/MichaIng/DietPi/blob/master/dietpi/func/dietpi-obtain_hw_model

CODE:       echo -e "$(mawk 'NR==2 {print $1}' /DietPi/dietpi/.hw_model)"
OUTPUT:     RPi

Have no fear the questions will come if i dead end somewhere

Thanks for your support at the start. Got me motivated to dig deep

@meeki007
From any interactive bash session and within DietPi scripts (where this is loaded: https://github.com/MichaIng/DietPi/blob/dev/dietpi/func/dietpi-globals#L89) you can use (( $G_HW_MODEL < 10 )) to check for RPi.

In case of scripts and other non-interactive shells, where globals are not loaded: G_HW_MODEL=$(mawk 'NR==1 {print}' /DietPi/dietpi/.hw_model)

This $FP_G_HW_MODEL_INDENTIFIER (/etc/.dietpi_hw_model_identifier) only exists on non-RPi. On RPi we do model detection based on revision code info on boot, so the SDcard can be swapped between different RPi models without having wrong values.

As reference since this should be merged, when we touch Chromium options: https://github.com/MichaIng/DietPi/issues/2575#issue-413358699

  • Hide cursor menu: [show] [hide] [hide on idle]

Merger of unclutter added to my field of view.

So I had to pick a place to start on all of this and it landed here.
dispalyresolutionbug

last night pecking around in bash getting my teeth cut again.

THIS DOES NOT WORK ITS JUST AN OUTLINE OF MY DIRECTION ive been playing with.

# RPi
        elif (( $G_HW_MODEL < 10 )); then

            local framebuffer_x=$(grep -m1 '^[[:blank:]]*framebuffer_width=' /DietPi/config.txt || vcgencmd get_config framebuffer_width)
            framebuffer_x=${framebuffer_x#*=}; framebuffer_x=${framebuffer_x:-0}
            local framebuffer_y=$(grep -m1 '^[[:blank:]]*framebuffer_height=' /DietPi/config.txt || vcgencmd get_config framebuffer_height)
            framebuffer_y=${framebuffer_y#*=}; framebuffer_y=${framebuffer_y:-0}
            local current_value=$(grep -m1 '^[[:blank:]]*dtoverlay=vc4-' /DietPi/config.txt | sed 's/^[^=]*=//') #OpenGL check 1st

            #Check if hdmi monitor/tv is detected and add values to an array
            #arrays
            hdmi_detected_array=()
            Mode=()
            #Monitor?
            local DMT_detected=$(tvservice -m DMT | grep -m1 'Group DMT' |  awk '{print $2}')
            #TV?
            local CEA_detected=$(tvservice -m CEA | grep -m1 'Group CEA' |  awk '{print $2}')
            #Add DMT & options to arrays
            if [[ "$DMT_detected" == 'DMT' ]]; then

                    hdmi_detected_array+=(tvservice -m DMT | grep -m1 'prefer' | cut -d ',' -f1 | cut -d ' ' -f6-)
                    Mode+=()

            #If framebuffer is not set by user then check if hdmi default is detected and being used
            if [[ "$framebuffer_y" == 0 ]] && [[ "$framebuffer_x" == 0 ]]; then


                    #Get default X,Y resolution
                    local framebuffer_x=$(tvservice -s | cut -d ',' -f2 | cut -d 'x' -f1 | awk '{print $NF}')
                    local framebuffer_y=$(tvservice -s | cut -d ',' -f2 | cut -d 'x' -f2 | awk '{print $1}')

            fi

The Idea is to get the output of tvservice -m DMT and tvservice -m CEA
into the G_WHIP_MENU_ARRAY

with fall back to the current menu if the hdmi is unplugged or the hdmi cant get data from the connected device.

Last thing we need is a breaking change caused by them updating tvservice output causing the menu to fail. So it needs to else to your menu if it cant get the info. Might have to check for some pattern matching to make this happen

@meeki007
To not make things too complicated ideally I would keep things separated, Chromium settings and display settings. It makes however sense, when user changes display resolution, that this changes the fallback Chromium resolution as well.

About framebuffer vs resolution:

  • Is there any reason why one would have a different (or even disabled) framebuffer size than display resolution?
  • To keep things simple I would keep both being changed together on RPi. Then resolution can be estimated via framebuffer dimensions as well (as it's currently done).
  • But yeah, to stay flexible it makes sense to detect resolution based on tvservice (if reliable) or edidparser to stay flexible/be failsafe. But this cannot be used within the resolution menu, since AFAIK a reboot is always required to apply settings. For a proper selection menu it is required to have the just chosen new settings shown, even if has not yet been applied due to outstanding reboot.

EDIT: Okay but I got your point now, just interpreted the tvservice call wrong:

  • Detect available modes for current screen and only show those in resolution menu, instead of all modes that theoretically exist.
  • This is even better since e.g. new modes could be added that we otherwise need to hard code. Only thing is that tvservice does not print the actual resolution for each available mode, does it?
  • I have currently video+framebuffer+VHCI completely disabled on my headless RPi. Will probably spin up a test install, as well based on current RPi4 compatible Raspbian Buster: https://github.com/MichaIng/DietPi/issues/2935
    Things might have changed there again, at least several new config.txt settings have been added...

tvservice does not print the actual resolution for each available mode

yes it does. here is the output:
tvservice -m DMT

Group DMT has 7 modes:
           mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive 
           mode 8: 800x600 @ 56Hz 4:3, clock:36MHz progressive 
           mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive 
           mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive 
           mode 22: 1280x768 @ 60Hz 15:9, clock:68MHz progressive 
  (prefer) mode 81: 1366x768 @ 60Hz 16:9, clock:85MHz progressive 
           mode 85: 1280x720 @ 60Hz 16:9, clock:74MHz progressive 

tvservice -m CEA

Group CEA has 17 modes:
           mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive 
           mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive 
           mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive 
           mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive 
           mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced 
           mode 6: 720x480 @ 60Hz 4:3, clock:27MHz x2 interlaced 
           mode 7: 720x480 @ 60Hz 16:9, clock:27MHz x2 interlaced 
  (native) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive 
           mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive 
           mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive 
           mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive 
           mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced 
           mode 21: 720x576 @ 50Hz 4:3, clock:27MHz x2 interlaced 
           mode 22: 720x576 @ 50Hz 16:9, clock:27MHz x2 interlaced 
           mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive 
           mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressive 
           mode 34: 1920x1080 @ 30Hz 16:9, clock:74MHz progressive 

You are correct about this needing to work on the pi 4

cana

Got a pi 4 - 2GB comming next week. Wanted the 4GB but better to have something onhand to test with.

I have to fly across the country next week so i will be out of the loop for 5-7 days

@meeki007
I am also thinking about ordering one ๐Ÿค”.

Safe journey!

Trying to wrap my head around the G_WHIP_MENU_ARRAY
Care to point me to where this is handled
where it puts it in
G_WHIP_RETURNED_VALUE

Need to figure this out if i want to have it auto create all the resolutions and then grab the right one and format it to be stored....

Well Well ..... got it detecting and then spiting it out in an array that matches the G_WHIP_MENU_ARRAY

root@DietPi:/home/dietpi# ./test.sh
DMT 81 : 1366x768 @ 60Hz 16:9 *Recommend
DMT 4 : 640x480 @ 60Hz 4:3
DMT 8 : 800x600 @ 56Hz 4:3
DMT 9 : 800x600 @ 60Hz 4:3
DMT 16 : 1024x768 @ 60Hz 4:3
DMT 22 : 1280x768 @ 60Hz 15:9
DMT 85 : 1280x720 @ 60Hz 16:9

Took some testing to align it all up

#!/bin/bash



  G_WHIP_MENU_ARRAY=('1' ': Display Options')
  # Hide Audio and Performance Options on VM
  G_WHIP_MENU_ARRAY+=(

    '2' ': Audio Options'
    '3' ': Performance Options'

  )
   G_WHIP_MENU_ARRAY+=(

    '4' ': Advanced Options'
    '5' ': Language/Regional Options'
    '6' ': Security Options'
    '7' ': Network Options: Adapters'
    '8' ': Network Options: Misc'
    '9' ': AutoStart Options'
    '10' ': Tools'

  )




#Check if hdmi monitor/tv is detected and add values to an array
#arrays
hdmi_detected_resolution_array=()
hdmi_detected_mode_array=()
#Monitor?
DMT_detected=`(tvservice -m DMT | grep -m1 'Group DMT' |  awk '{print $2}')`
#TV?
CEA_detected=`(tvservice -m CEA | grep -m1 'Group CEA' |  awk '{print $2}')`
#Add DMT & options to arrays
if [[ "$DMT_detected" == 'DMT' ]]; then
    #Grab preferd resolution from this list first and add it to the start of the array
    hdmi_detected_resolution_array=("`tvservice -m DMT | grep -m1 'prefer' | cut -d ':' -f1 | cut -d ' ' -f4- | sed 's/mode/DMT/'`" "`tvservice -m DMT | grep -m1 'prefer' | cut -d ',' -f1 | cut -d ':' -f2- | sed 's/ /: /' | awk '{print $0" *Recommend"}'`")

    #TESTING REMOVE THIS LINE AND COMMENT BEFORE PRODUCTION RELESE
    echo ${hdmi_detected_resolution_array[0]} ${hdmi_detected_resolution_array[1]}
    COUNTBY2=2

    #Add the rest of the detected resolutions to the array
    #Usable info starts at line 2
    DMT_LineNumber=2
    DMT_Nullcheck=`(tvservice -m DMT | grep -vwE 'prefer' | awk -v LineNumber="$DMT_LineNumber" 'NR==LineNumber')`
        until [ ! "$DMT_Nullcheck" ] || [ $DMT_LineNumber -gt 100 ] ; do
        hdmi_detected_resolution_array+=("`tvservice -m DMT | grep -vwE 'prefer' | awk -v LineNumber="$DMT_LineNumber" 'NR==LineNumber' | cut -d ':' -f1 | cut -d ' ' -f12- | sed 's/mode/DMT/'`" "`tvservice -m DMT | grep -vwE 'prefer' | awk -v LineNumber="$DMT_LineNumber" 'NR==LineNumber' | cut -d ',' -f1 | cut -d ':' -f2- | sed 's/ /: /'`")

        #TESTING REMOVE THIS LINE AND COMMENT BEFORE PRODUCTION RELESE
        echo ${hdmi_detected_resolution_array[$COUNTBY2]} ${hdmi_detected_resolution_array[$COUNTBY2+1]}
        let COUNTBY2=COUNTBY2+2

        let DMT_LineNumber=DMT_LineNumber+1
        DMT_Nullcheck=`(tvservice -m DMT | grep -vwE 'prefer' | awk -v LineNumber="$DMT_LineNumber" 'NR==LineNumber')`
    done



fi



#echo ${hdmi_detected_resolution_array[2]}

#echo ${hdmi_detected_resolution_array[*]}


#echo ${G_WHIP_MENU_ARRAY[*]}

#echo ${G_WHIP_MENU_ARRAY[0]}

NOW WOULD YA LOOK AT THAT!!!

yepyep

Auto detecting resolution :)

And when I unplug the HDMI cable and reboot it should load into the original menu system..........

AND IT FAILS :( SO CLOSE ...... more work

nopenope

oh code added .txt to end
dietpi-config.txt
..... encase i get hit by a bus tomorrow someone else can continue my work

@meeki007
Wow impressive work, many thanks for this!

I opened a new issue about this: https://github.com/MichaIng/DietPi/issues/2939

  • I also plan to put SDTV/LCD/headless as separate options so that resolution menu only shows up when HDMI output is selected.

Hi Guys,

sorry for coming back to this after such a long time :)

The original post started with a request to hide error dialog's on Chromium while using the Kiosk mode. I see --incognito could be an option but would have some downside as well. Was there any other solution?

@Joulinar
Indeed we've gone out of topic meanwhile. See: https://github.com/MichaIng/DietPi/issues/2938#issuecomment-506393195

  • Adding --app=$URL + removing --kiosk and the $URL from elsewhere on chromium options seems to be the solution to run Chromium in app mode which hides the error dialog.

@MichaIng
Jep indeed that's it. thx

It seems the order of the switches matters. e.g. adding --app overrides --kiosk. Also, I found that --noerrdialogs needed to be appended to the end (I mistakenly put it at the start where it didn't appear to take effect).

Jep app overriding kiosk is also what I found, but was not able to have it the other way round, hence not sure if the order counts.

What counts about the order is that one needs to take care to not add an argument/option to the xinit command, hence it must be applied after the chromium command/binary.

--noerrdialogs at least has no effect on the prompt to restore last session as this is no error :wink:.

I just discovered that you can get Chromium to start at the correct resolution if you wrap it in a script.

Basically:

  1. move almost everything from /var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh to /var/lib/dietpi/dietpi-software/installed/chromium-autostart-real.sh
  2. edit the latter so that the xinit prefix is removed, just let it launch Chromium
  3. edit /var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh so that it only contains the following command:

    xinit /var/lib/dietpi/dietpi-software/installed/chromium-autostart-real.sh
    

Finally, in the "real" Chromium script you can fetch the resolution with xrandr:

RES_X=$(xrandr | grep \* | awk '{print $1}' | cut -d "x" -f 1)
RES_Y=$(xrandr | grep \* | awk '{print $1}' | cut -d "x" -f 2)

Unrelated, but useful to know: you can also start unclutter or other utilities while in the script started by xinit as DISPLAY would be set.

Too bad that Chromium on DietPi shows with a 16-bit depth unless you disable the GPU compositing, but that's another topic.

Edit: the last point seems to have vanished after a reinstall. ๐Ÿค”

Was this page helpful?
0 / 5 - 0 ratings