openDsh / dash

Join us on Slack! https://join.slack.com/t/opendsh/shared_invite/zt-la398uly-a6eMH5ttEQhbtE6asVKx4Q
GNU General Public License v3.0
238 stars 69 forks source link

Raspi Buster (lite) 3rd party app load issue #111

Open 7ensation opened 2 years ago

7ensation commented 2 years ago

Description of problem:

This software is awesome thanks for all your hard work! I am having an issue with just the lite version of Buster on a pi 4 2GB. I have 2 boot drives one running the GUI version of Buster and the issue is not repeatable on the desktop version. But I have a small pyqt5 gui application to control some relays in my car and when I use the app launcher on the buster lite build to run the .py script, my GUI comes up but the screen is off center and my GUI persists in front of everything even if I click on the other tabs such as camera or android auto. If I close the app the Dash GUI returns to normal. Again it works perfectly on the Desktop version of Buster. Id like to use the lite version though so I can just load my custom splash screen and boot right into the Dash app without seeing the raspi desktop. TIA!

Hardware

Device Connection Method Screen Mobile Device Android Auto Version
Raspberry Pi 4 4GB USB Cable Official Raspberry 7" Screen Galaxy s21 ultra

Installation Method: Install.sh

robert5974 commented 2 years ago

Did you happen to pass the QMainWindow the WindowStaysOnTopHint window flag (or use setWindowFlags)?

7ensation commented 2 years ago

no I didnt use anything like that in the pyqt5 app. I looked and i use setFixedSize() because my app is built for use on the official 800x480 7" touchscreen. However it works fine and actually rescales nicely on the desktop version of buster.

robert5974 commented 2 years ago

I think that might be the problem. @rsjudka can probably tell you better but I think making it a fixed size might be restricting the dash app launcher from resizing the window to fit it.

If it can't do that then maybe it never gains control of focus.

Robert Crowley

On Sun, Jan 23, 2022, 7:02 PM 7ensation @.***> wrote:

no I didnt use anything like that in the pyqt5 app. I looked and i use setFixedSize() because my app is built for use on the official 800x480 7" touchscreen. However it works fine and actually rescales nicely on the desktop version of buster.

— Reply to this email directly, view it on GitHub https://github.com/openDsh/dash/issues/111#issuecomment-1019597600, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLUDVAA2G34SRNHL6IEZO3UXSJKBANCNFSM5MT6ZAFA . You are receiving this because you commented.Message ID: @.***>

7ensation commented 2 years ago

so i just removed the fixed dimensioning but no dice unfortunately :/

robert5974 commented 2 years ago

Ok. I'll poke around to see what else it could be unless someone else gives you a solution.

Robert Crowley

On Sun, Jan 23, 2022, 7:22 PM 7ensation @.***> wrote:

so i just removed the fixed dimensioning but no dice unfortunately :/

— Reply to this email directly, view it on GitHub https://github.com/openDsh/dash/issues/111#issuecomment-1019604091, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLUDVEOBHFH2ZF7QLNENWTUXSLUVANCNFSM5MT6ZAFA . You are receiving this because you commented.Message ID: @.***>

7ensation commented 2 years ago

yeah here's the code for the pi app if you want to load it. requires the to install adafruit dht sensor library (sudo pip3 install adafruit-circuitpython-dht) and pyqt5 (sudo apt-get install python-pyqt5) slc_gui.zip

rsjudka commented 2 years ago

hmm so looking at your project...

self.left = 100
self.top = 100

is that not offsetting 100px from the top left corner? It also looks like the stylesheets have some hardcoded dimensions in there (not sure how that would affect it tho)

how are you setting up your GUI on the lite image?

7ensation commented 2 years ago

thats just the starting position of the window but it can be dragged or reposition. And im not a great gui programmer by any stretch but i cant imagine the issue is inside of my python GUI if it acts as expected and positions perfectly on the desktop buster build.

And for your second question are you referring to my GUI or the Dash GUI? I installed X to manage the graphics of Dash on the lite version, and then my personal GUI just gets launched from the 3rd party app launcher, nothing special there.

7ensation commented 2 years ago

For now I switched back to the desktop version of Buster. I posted a YouTube vid showing how it looks and functions correctly.

https://youtu.be/JEVaeN5_SK0

icecube45 commented 2 years ago

I have a lite image loaded up on my test Pi right now, so I'll try and put some hours in on investigating this

7ensation commented 2 years ago

awesome thanks! let me know if ya find anything

icecube45 commented 2 years ago

Completely unrelated, any chance you have a writeup on your lite install? (splashscreen, boot speed improvements, that kinda thing). Always looking to improve my own setup (and there's always a slim chance it relates to your issue)

7ensation commented 2 years ago

oh geez ill try to remember but i started documenting but ill probably need to do it again cuz i may have forgotten some steps.... but here goes: (also a lot of credit goes to others as i scoured the github here for various solutions)

  1. Ensure Buster version is installed
  2. Clone github repository https://github.com/openDsh/dash
  3. Run the install.sh script
  4. If using lite image install x and gstreamer a. sudo apt install --no-install-recommends xserver-xorg-video-all xserver-xorg-input-all xserver-xorg-core xinit x11-xserver- utils git b. sudo apt install gstreamer1.0-plugins-good gstreamer1.0-omx
  5. Once complete downgrade firmware of pi to fix white screen on android auto a. sudo rpi-update 15471b6e99b6db2f3206f0aed67d0aebbfc9f9cf
  6. Remove cursor permanently a. Add the below line to ‘/etc/lightdm/lightdm.conf’ to the bottom of the [seat:*] section xserver-command = X -nocursor
  7. Python application dependency need to be installed a. Sudo apt-get install python-pyqt5 b. Sudo pip3 install adafruit-circuitpython-dht
  8. Disable pi splash screen in /boot/config.txt a. Add ‘disable_splash=1’ in the #dtoverlay=vc4 section
  9. Edit /boot/cmdline.txt to quiet the screen. Append: a. console =tty3 quiet splash loglevel=3 logo.nologo vt.global_cursor_default=0 plymouth.enable=0
  10. create /home/pi/.xinitrc

    !/usr/bin/env sh

    xset -dpms
    xset s off
    xset s noblank
    
    while [ true ]; do
         sh /home/pi/run.sh
    done
  11. create /home/pi/run.sh

    !/usr/bin/env sh

    /home/pi/dash/bin/dash >> /home/pi/dash/bin/dash.log 2>&1
    
    sleep 1
  12. Append to /home/pi/.bashrc if [ "$(tty)" = "/dev/tty1" ]; then startx > /dev/null 2>&1 fi

    this runs everything automatically without reporting anything to the screen until tty1 starts and thats super annoying and i have it in my notes to try the following step to silence that but i havnt had a chance yet:

Adding 'rd.udev.log-priority=3' to the kernel cmdline.txt

anyways give that a try

icecube45 commented 2 years ago

@7ensation still trying to figure this out - but because I saw you mention you downgraded the firmware for the whitescreen issue - could you grab your pi revision code for me? Should be at the bottom of a cat /proc/cpuinfo

7ensation commented 2 years ago

sure rev code b03114

icecube45 commented 2 years ago

Thank you - also unrelated (but potentially related to white screen bug), what phone are you using to connect to AA?

7ensation commented 2 years ago

Thank you - also unrelated (but potentially related to white screen bug), what phone are you using to connect to AA?

It's a Galaxy s21 ultra

icecube45 commented 2 years ago

Hijacking this once again 😅 I have a workaround for the white screen issue in my branch of openauto - it adds a new setting in openauto.ini that needs to be set to true, but should work after that. Note that it requires h264bitstream to be installed image

Just informing those affected until this is (hopefully) fixed upstream

rsjudka commented 2 years ago

hey sorry this fell off my radar for a bit!

ill try getting a lite build to test going and do some debugging on the app launcher

jmccoy555 commented 2 years ago

Also think I am seeing this. Testing a very basic file (and the one in slc_gui.zip) appears to work in the desktop version, but it takes over in lite. Bullseye 64bit. Followed the instructions above less the downgrade.

Any ideas before I start again with a desktop install? Happy to test too. Thanks.

rsjudka commented 2 years ago

so i tried a couple apps and this is what I was seeing...

@7ensation how long does it take for slc gui to launch for you? it might be possible dash gives up waiting for the window to come up (which is something ive noticed with apps that are heavier and/or run alot of things in the background before launching the actual window)

7ensation commented 2 years ago

so i tried a couple apps and this is what I was seeing...

  • regular executables seems to work just fine on a lite image
  • i didnt have any issues launching the slc gui, but I did notice it doesnt fill the entirety of the dash frame (which might be related to the hardcoded size i mentioned earlier)

@7ensation how long does it take for slc gui to launch for you? it might be possible dash gives up waiting for the window to come up (which is something ive noticed with apps that are heavier and/or run alot of things in the background before launching the actual window)

Thanks for keeping up on this. I havnt measured the time but it seems it opens pretty instantly. I think I had changed the code to auto fit but it still was functioning the same.

rsjudka commented 2 years ago

oh yeah i was talking like a couple seconds of delay hah so that wouldn't be an issue

so write a super simple pyqt app

from PyQt5.QtWidgets import QApplication, QWidget, QLabel

app = QApplication([])
widget = QWidget()
label = QLabel(widget)
label.setText("Hello World!!")
widget.show()
app.exec_()

and it seems to work without any issues

@jmccoy555 can you share the pyqt app you tested with?

7ensation commented 2 years ago

oh yeah i was talking like a couple seconds of delay hah so that wouldn't be an issue

so write a super simple pyqt app

from PyQt5.QtWidgets import QApplication, QWidget, QLabel

app = QApplication([])
widget = QWidget()
label = QLabel(widget)
label.setText("Hello World!!")
widget.show()
app.exec_()

and it seems to work without any issues

@jmccoy555 can you share the pyqt app you tested with?

So is there any obvious reason as to why some applications load correctly on the desktop version but not the lite version?

jmccoy555 commented 2 years ago

oh yeah i was talking like a couple seconds of delay hah so that wouldn't be an issue

so write a super simple pyqt app

from PyQt5.QtWidgets import QApplication, QWidget, QLabel

app = QApplication([])
widget = QWidget()
label = QLabel(widget)
label.setText("Hello World!!")
widget.show()
app.exec_()

and it seems to work without any issues

@jmccoy555 can you share the pyqt app you tested with?

Hi, sorry its been a long weekend here so have been away. I'm pretty sure this worked on the full version. I will rebuild it now to double check. On the lite it just sits in the top left on top of dash.

#!/usr/bin/env python3

# -*- coding: utf-8 -*-

# Form implementation generated from reading ui file 'onOff.ui'
#
# Created by: PyQt5 UI code generator 5.15.4
#
# WARNING: Any manual changes made to this file will be lost when pyuic5 is
# run again.  Do not edit this file unless you know what you are doing.

from PyQt5 import QtCore, QtGui, QtWidgets

class Ui_Form(object):
    def setupUi(self, Form):
        Form.setObjectName("Form")
        Form.resize(400, 300)
        self.toolButton = QtWidgets.QToolButton(Form)
        self.toolButton.setGeometry(QtCore.QRect(190, 130, 33, 34))
        self.toolButton.setObjectName("toolButton")

        self.retranslateUi(Form)
        QtCore.QMetaObject.connectSlotsByName(Form)

    def retranslateUi(self, Form):
        _translate = QtCore.QCoreApplication.translate
        Form.setWindowTitle(_translate("Form", "Form"))
        self.toolButton.setText(_translate("Form", "..."))

if __name__ == "__main__":
    import sys
    app = QtWidgets.QApplication(sys.argv)
    Form = QtWidgets.QWidget()
    ui = Ui_Form()
    ui.setupUi(Form)
    Form.show()
    sys.exit(app.exec_())
jmccoy555 commented 2 years ago

@rsjudka Just tried with your 'hello world'..... on boot I can see it in the top left whilst dash is loading, once loaded dash takes over and it must be hidden away in the background.

rsjudka commented 2 years ago

hmm well this is baffling... not too sure what what could be a factor here besides from how x11 gets installed?

I'm using a lite image from @icecube45 who might be able to speak more to how that gets built (compared to how you setup your lite build mentioned above)

robert5974 commented 2 years ago

Could it be based on resolution by any chance? Between you what kind of screens are being tested on? My raspberry pi 7" touchscreen does different things than my HDMI monitor in the house sometimes like on boot.

7ensation commented 2 years ago

Good thought, I know in Linux HDMI and screen things are loaded at the kernel level. I'm personally using the official pi 7" screen.

jmccoy555 commented 2 years ago

Waveshare 10.1inch 1920×1200 normally but plugged it into my desktop monitor today, same behaviour.

icecube45 commented 2 years ago

Yea, can confirm I'm not seeing this in bullseye (x64) lite, but I swear I saw it before.. maybe an apt upgrade along the ways resolved it? @jmccoy555 have you tried running an apt upgrade recently?

jmccoy555 commented 2 years ago

Yep, pretty sure I did an update along the way. Just done one now too and still the same :cry: @icecube45 did you install with the steps outlined above too?

Just done a git pull and a rebuild.... still the same, but now I can have a clock!! :smile:

jmccoy555 commented 2 years ago

Maybe, just maybe it is something to do with me needing to add #!/usr/bin/env python3 to the top of the .py file that I load with the app launcher?? But without that line it doesn't work.

icecube45 commented 2 years ago

My builds are generated via the scrips here - but at a quick glance the x install is identical - don't cite me on that though.

I tested the slc_gui zip above, which does have the python3 crunchbang on the file

rsjudka commented 2 years ago

@jmccoy555 @7ensation could you guys post your versions of raspberry pi os and xlib (and anything else that might be relevant)?

and just for reference not having the shebang (or crunchbang - haven't heard that one ever tho hah) will have it run with the default python version (which is still 2.7 on the pi's i believe)

jmccoy555 commented 2 years ago

@rsjudka

Think this is what you're after???

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"

BUG_REPORT_URL="https://bugs.debian.org/"
Linux openDash 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux
ii  xorg-sgml-doctools                     1:1.11-1.1                       all          Common tools for building X.Org SGML documentation
ii  xserver-xorg-core                      2:1.20.11-1+rpt1+deb11u1         arm64        Xorg X server - core server
ii  xserver-xorg-input-all                 1:7.7+22                         arm64        X.Org X server -- input driver metapackage
ii  xserver-xorg-input-libinput            0.30.0-1                         arm64        X.Org X server -- libinput input driver
ii  xserver-xorg-video-all                 1:7.7+22                         arm64        X.Org X server -- output driver metapackage
ii  xserver-xorg-video-amdgpu              19.1.0-2                         arm64        X.Org X server -- AMDGPU display driver
ii  xserver-xorg-video-ati                 1:19.1.0-2                       arm64        X.Org X server -- AMD/ATI display driver wrapper
ii  xserver-xorg-video-fbdev               1:0.5.0-1                        arm64        X.Org X server -- fbdev display driver
ii  xserver-xorg-video-nouveau             1:1.0.17-1                       arm64        X.Org X server -- Nouveau display driver
ii  xserver-xorg-video-radeon              1:19.1.0-2                       arm64        X.Org X server -- AMD/ATI Radeon display driver
ii  xserver-xorg-video-vesa                1:2.5.0-1                        arm64        X.Org X server -- VESA display driver
qmake --version
QMake version 3.1
Using Qt version 5.15.2 in /usr/lib/aarch64-linux-gnu
rsjudka commented 2 years ago

looks like our x versions match but... very different os

PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Linux InfinitiG37 5.10.63-v7l+ #1488 SMP Thu Nov 18 16:15:28 GMT 2021 armv7l GNU/Linux

one last thing, what version of Qt do you have (given you have a different kernel and arch)?

pi@InfinitiG37:~ $ qmake --version
QMake version 3.1
Using Qt version 5.15.2 in /usr/lib/arm-linux-gnueabihf
jmccoy555 commented 2 years ago

@rsjudka - QMake added above. All looks the same.

So you are using the 32bit version?

I'm using the 64bit image downloaded a could of weeks ago now I guess that doesn't come with the pi user anymore.

icecube45 commented 2 years ago

@rsjudka yea, you're using the 32 bit version (the 64 bit version technically isn't raspbian, but debian, hence the difference in OS)

That being said, I tested this on the 64 built version (built the same way as @rsjudka's image) with no issues. Though to be fair, my 64 bit version is a month or two out of date?

jmccoy555 commented 2 years ago

Ok, sounds like I could do with doing a few tests then with current 32bit install and 64bit image built (just need to work out how that repo works 😕 )

I think when I tried with 64bit a few months ago it still had the Pi user. So maybe there some other changes in there that have tripped things up.

I'm away for a bit but will give it ago asap.

7ensation commented 2 years ago

So I got back on this and i tried wiping and reinstalling from scratch on a buster lite image following all my previous steps. now once the pi is booted its just a black screen. nothing. did something change? did anyone else follow my steps exactly and have the same issue? super frustrating

it just will not connect to an x display.

rsjudka commented 1 year ago

hmm any changes to dash were basically feature additions... nothing that would affect the boot of the pi tho

is not connecting to an x display something that was always there or just after you did the dash "install" stuff?

rsjudka commented 1 year ago

or maybe related to #63?

jmccoy555 commented 1 year ago

Hi, finally found a few hours to get a fresh 64bit Bullseye Desktop install set up. This is with the Pi image downloaded today and the latest pull of openDash. Using this as a test

#!/usr/bin/env python3

from PyQt5.QtWidgets import QApplication, QWidget, QLabel

app = QApplication([])
widget = QWidget()
label = QLabel(widget)
label.setText("Hello World!!")
widget.show()
app.exec_()

it appears to load twice, once correctly but then again on top. If I try my button test from above then it hides the Android Auto button.

2022-07-29-124347_2560x1440_scrot

Will try a 32bit Bullseye desktop install next.

Edit - Launching the app loader in 32bit Bullseye Desktop causes dash to crash! Looks like its back to Buster for the time being.

Edit 2 - back to Bullseye 64bit - ticking 'launch at startup' and restarting appears to sort things out

rsjudka commented 1 year ago

@jmccoy555 sorry for replying so late!

so using launch at startup makes it work correctly every time? But when manually load your app it crashes?

jmccoy555 commented 1 year ago

@jmccoy555 sorry for replying so late!

so using launch at startup makes it work correctly every time? But when manually load your app it crashes?

32bit Bullseye Desktop causes dash to crashes every time.... I was only interested in 32bit as I thought it may be an option to resolve the positioning issue.

64bit Bullseye Desktop sorts it self out once I tick the launch on startup and restart. Not seen the overlaying issue since (obviously it comes back if I readd the app or a second copy). Once I found this worked I haven't tried 32bit since.

I think I'll stick with Desktop over lite going forwards as it give comparable boot times, a bit more flexibility (Bluetooth connections are easier to make etc.) and if you set a black desktop and taskbar, remove the icons you don't want from both you can't really tell.

maskaz commented 1 year ago

I made app on PyQt5 and have problem with load it. Dash hangs for a moment and do not loads app. Code to the app if some one wanna try/test: https://github.com/maskaz/CallControl_dev

7ensation commented 1 year ago

finally got a chance to revisit this. First I reinstalled a fresh bullseye 64 lite image onto a boot drive and got it functional. installed dash functionally. then i tested with the old slc-gui app linked above with same results. I then proceeded to use qt creator to make a few very simple pyqt5 applications with Very simplistic GUIs. basically just a couple buttons on the main ui form widget. all of them stick to the top left of the screen when dash loads them then proceed to disappear alltogether unfortunately. a small update since i was thinking it had something to do with the dimensions in the slc gui app.

maskaz commented 1 year ago

To "stick" 3rd app into dash window: install and run openbox (so startx, start openbox, start dash)

7ensation commented 1 year ago

To "stick" 3rd app into dash window: install and run openbox (so startx, start openbox, start dash)

Have you tested this with the above linked app? I had openbox running on my setup yesterday and it didn't fix the issue.