37:00 QT Gui card system discussed.
(Posted this in the comments at Youtube, but this is the better place for it)
To comment on the QT-GUI card system. I don’t think it is that bad ! See my quick and dirty demo from May this year;
Resolution of that screen is 720p and overall size is perhaps bigger as the smaller sized screen, but if it comes to the card system working YES or NO, I don’t think it is bad at all. Indeed some further tweaking would be nice, but nothing fancy.
Look at the weather skill for multiple cards
Look at the date for a simple one card without backgroud
Look at the wiki skill for a one card including background.
Oh and btw, (and this is more for @ken-mycroft) do you see those LED’s lighten up as they should. The whole mycroft software stack and therefor the skill itself runs as a mycroft user NOT as root.
C’mon guys, really? Sudo to control a couple of led’s… (The solution has been talked about multiple times and lies in udev, the right group for the gpio and make sure the user running the software is within that group. Ping me and I will have a look how to help you)
*sarcasm with a wink mode off
Just finished watching the last dev-sync of the 28th, but as there is no thhread yet, going to comment on it here where above video demostrates the performance as well.
It kind of suprises me that you guys doubt the performance of the GUI while those parts are easily handled by the gpu’s nowadays.
You start the dev-sync about precise running at 45% continously for 4 cores and then debate the performance of the GUI?
QT5 is being handled by the GPU. I don’t know Kivy (yet) but almost sure it is also handled by he GPU.
Above video is QT5.12 LTS with the KF5 framework running on Wayland fully hardware accelerated by the GPU. It hardly consumes either memory or cpu cycles or at least compared to precise. Most (if not all) of the “thinking” time of mycroft is because of the actual Python software and network polling/delays
Yes, qml has to be compiled at runtime and might take some micro seconds, but even that is cached within the users home directory.
More than happy to give you guys some numbers. Just let me know what you guys would like to see/test/benchmark
So, I just saw this. I must admit I am a bit confused. First I don’t know what you mean by ‘do you see those LEDs lighten up’. Now when you reference group permissions yes, but at the end of the day that group will need elevated privileges anyway to hit the geopixel code with the gating factor not being the GPIOs as I understand it but rather the use of /dev/mem. These are not your grandfather’s LEDs, these are basically a daisy chain of serial devices supporting 256 bit color. Consider this a ping and feel free to email me at email@example.com. I would love nothing better than to not need elevated abilities to control a LED.
Regarding 28th dev meeting
QT runs fine even on a pi3, not even a b+ , it also runs on android…
I don’t understand why Kivy was even made, this was the only part of the mark2 that was ready, why throw away 2 years of perfectly good work? not even to mention all the skills that wont be cross compatible…
I’d love to see the rationale behind the whole Kivy debacle, but a dev meetings is probably not the place for it, as you said the performance issue mostly comes from precise, it should have been migrated to tflite or something instead of devoting resources to a new GUI implementation
*crap, the sarcasm wink thingy did not get through. Should have used smileys.
Meant, the respeaker stuff just running under a normal user conteolling the spidev stuff from python without the need for sudo.
Started of the wrong foot here. Will email you.
No worries. I am not thin skinned and I appreciate the input. Just that the respeaker LEDs go through the USB interface if I am not mistaken. The SJ201 is directly controlled. But seriously, if there is a way to handle those LEDs without using sudo I would love to do that.
You can add the user to the gpio group, and that should allow them access to the relevant pin devices, but not to /dev/mem if that’s the only concern.
Hey, we originally looked into the Kivy Framework late last year when we were having trouble getting Qt to run reliably. Things have changed a lot since then and a lot of the dependencies are now available in the mainstream repo’s which makes it all a lot more straight forward. As you’ve shown, I think the Qt framework is running great now.
I’ve been having a quick look at system monitoring and reporting packages so we can get some real data on the resource usage. Will probably also create a baseline against Picroft with no GUI at all. At the moment I’m leaning toward nmon but any other suggestions welcomed.
Quick & Dirty show case;
mycroft 20.8.0 (ae72ebd247f877f643573791650e63c4044604d1)
mycroft-gui 1.0 (2212941674de7f23fc0aa076b7051deb5ada0856)
HDMI screen in 1920x1080 resolution (worst case type of scenario)
Linux: Linux version 5.4.68-v8
Build: (gcc version 9.3.0 (Buildroot 2020.02.6-59-g85b5f2c6ff-dirty))
Release : 5.4.68-v8
Version : #1 SMP PREEMPT Thu Oct 1 08:14:22 CEST 2020
cpuinfo: CPU architecture: 8
cpuinfo: BogoMIPS : 108.00
cpuinfo: CPU part : 0xd08
number of CPUs: 4
Machine : aarch64
Nodename : MycroftOS-7aadc9
lsb_release: not found
Basically the weather skill is the most demanding skill as it runs multiple cards at the same time all with animated pictures.