**** BEGIN LOGGING AT Thu Jun 28 03:00:02 2018 Jun 28 10:08:35 hi, any links on how to run QtGui applications without XServer Jun 28 10:08:36 ? Jun 28 10:09:12 on beaglebone Jun 28 10:11:43 qt can render to framebuffers and such Jun 28 10:14:11 do I need to change my code to make it work? Jun 28 10:18:31 I haven't looked at it in ages. Jun 28 10:19:49 http://doc.qt.io/qt-5/embedded-linux.html Jun 28 10:21:39 thx **** BEGIN LOGGING AT Thu Jun 28 11:35:20 2018 Jun 28 11:38:55 I did export QWS_DISPLAY=LinuxFB:mmWidth=310:mmHeight=190 Jun 28 11:39:06 and then I run the app with -qws Jun 28 11:39:26 but it says that It cannot connect to display Jun 28 11:39:31 any ideas? Jun 28 11:58:44 unless you are using ancient QT, there is no qws (according to the documentation I linked to earlier) Jun 28 12:02:06 hmmm, that's true Jun 28 12:23:15 well running ./app -platform linuxfb worked Jun 28 12:23:51 but there is no mouse or keyboard Jun 28 12:26:39 there is evdev tuning afterwards Jun 28 12:28:18 ok, but it seems that bbb doesn't use the gpu Jun 28 12:29:05 that what I meant in my "wayland" message, please re-read that Jun 28 12:30:51 yes luneff, thanks a lot Jun 28 12:32:04 that's isn't an easy issue to solve, I got by only by using Yocto and writing handmade patches to Qt and other recipes, which got quite resembling to meta-b2qt layer (one that is official with Qt on various embedded platforms) Jun 28 12:34:22 https://e2e.ti.com/support/arm/sitara_arm/f/791/t/415073?Beaglebone-GPU-not-being-used Jun 28 12:36:34 does the beagle-x15 have the same issues? Jun 28 12:37:15 it's not a hardware limitation Jun 28 12:38:03 I know Jun 28 12:40:34 I will also try with ti-processor-sdk Jun 28 12:42:16 thanks ppl :) Jun 28 12:42:22 I will keep you posted Jun 28 12:46:06 luneff: no wayland is required Jun 28 12:46:56 the linuxfb qpa doesn't use the gpu. getting input requires a bit of magic stuff (see http://doc.qt.io/qt-5/embedded-linux.html ) Jun 28 12:47:15 oh well… Jun 28 12:47:24 the eglfs backend uses gpu acceleration without requiring wayland Jun 28 12:47:39 (he dropped 7min ago) Jun 28 12:47:50 oh Jun 28 12:48:14 luneff: "no EGLFS, unfortunately :-(" eglfs works for me Jun 28 12:50:33 ... after patching qtbase to use 16-bit pixel format at least. if you're as lazy as me and don't want to recompile qtbase, feel free to try https://liktaanjeneus.nl/sgx/patch-qt5-eglfs_kms.pl Jun 28 12:51:57 (disclaimer: reading the script may cause a burning sensation) Jun 28 12:53:04 uhm. aren't official TI drivers for the arm35xx wayland-only? if so, I guess I went a wrong route a year ago Jun 28 12:53:11 *if they aren't Jun 28 12:53:54 you mean am335x (the am35xx exists too and isn't remotely similar) Jun 28 12:54:57 the drivers have three platform integrations: wayland, DRM, and GBM Jun 28 12:55:07 the latter two work directly on fullscreen without any window system Jun 28 12:55:35 (since recently there's also an experimental one for x11 dri3: https://github.com/TexasInstruments/dri3wsegl ) Jun 28 12:56:28 when running without a window system, the DRM backend is automatically selected Jun 28 12:56:36 (e.g. for qt5 eglfs) Jun 28 12:56:50 I think the GBM backend is used by the wayland server Jun 28 13:13:14 uh ;-( I probably should have skipped all the weston mess for my fullscreen app then... didn't really had time to think back then and now it is in production already :-D Jun 28 13:14:26 good to hear the wayland way works too! never got around to trying that Jun 28 13:20:03 I had to patch weston so it doesn't allow to drag window whenever it thinks it is stuck (only desktop shell worked for me) :-D Jun 28 13:30:25 you can use qt-as-wayland-server-ish. Jolla use it for Sailfish, their homescreen app hosts everything Jun 28 13:39:53 hi guys trying to figure out my boot issue with archlinux arm on the pocketbeagle. followed these instructions here, https://archlinuxarm.org/forum/viewtopic.php?f=48&t=12623, after installing as it wouldnt boot with the regular beaglebone black instructions. I cloned and compiled u-boot cross compiling from ubuntu and flashed the mlo and .img and still am not able to boot the pocketbeagle this is what i see in my serial console on boot https://paste Jun 28 13:39:53 bin.com/NDk0tfwT Jun 28 13:42:16 that sure looks wonky Jun 28 13:46:02 lol Jun 28 13:46:58 not sure what i can do to fix it. Jun 28 13:47:06 zmatt: regarding my question about the DSP, I made the application root suid for now. I'll have to find ways to manage the security issues this will cause. Jun 28 13:48:34 raffo: well like I said, from a security point of view an application that can load software onto the DSPs has full system access Jun 28 13:48:52 oh maybe not Jun 28 13:49:05 I just realized the DSPs have MMUs managed by linux Jun 28 13:49:50 assuming the DSPs can't mess with the MMUs themselves (that may itself depend on details of the setup) that might actually create a security barrier Jun 28 13:50:31 but why suid root? it explicitly needs to be invoked by an unprivileged user? can't it run a service? Jun 28 13:52:19 and like I said, it's typically possible (and indeed typically not hard) to grand unprivileged access to stuff, but since I don't know any details about how the DSPs are managed in linux I can't tell you any specifics of what the udev rules would have to look like Jun 28 13:52:24 *grant Jun 28 14:14:11 zmatt: the suid is for testing. I'm adding DSP functions to an existing application which is part of a larger package. I don't want to run the whole thing as root, only this particular sub-application. Jun 28 15:35:17 hello? Jun 28 15:36:11 I have a few questions on the beagle board black? Really new to beagle board products? Jun 28 15:36:51 you're uncertain whether or not you have question about the beaglebone black? Jun 28 15:36:56 *questions Jun 28 15:37:59 I want to know how good is the bone black at handling motors and servos Jun 28 15:38:26 that's a rather vague question Jun 28 15:38:58 the reason is is that the bone blue doesn't seem to have any pin outputs for regular sensors to control the motor and to handle LEDs but the black seems simple, and has more resources Jun 28 15:39:19 the blue is basically the black + robotics cape integrated Jun 28 15:39:55 the blue does still have various headers that connect to a bunch of processor IO usable for misc purposes Jun 28 15:40:12 the bone blue can control 8 servos and 4 motors but it seems its limited to that. My question is I guess can I do the same thing with the black? If not can I get a servo/motor extention like a shield? Jun 28 15:40:44 the main thing to keep in mind is that all the digital gpio of the beaglebone black are 3.3v and have very limited current driving capability Jun 28 15:41:39 so e.g. for motors you will need external motor drivers (the blue has these integrated) Jun 28 15:43:57 So I should go with the blue Jun 28 15:44:27 Could you give me a reference or some sort of video showing me the gpio pins that are with the bone blue? Jun 28 15:44:51 you haven't really specified your needs/constraints well enough to give much advice Jun 28 15:45:39 I'm building an R2 unit and I'm hoping to use ROS /ubuntu to drive the robot autonomously which will need 5v output at least for most things used Jun 28 15:46:08 the black offers more io and more flexibility, but you will need more complicated electronics to interface stuff for robotics Jun 28 15:46:26 the blue makes things simpler, but only if the resources it provides happen to suffice for your needs Jun 28 15:46:49 well I'm curious where the sensors are supposed to be hooked up and LEDs for your basic output pins I know where the motors and servos go Jun 28 15:46:59 define "sensors" Jun 28 15:48:15 it has four inputs for quadrature encoders, it has an i2c bus connection, it has gpios Jun 28 15:49:01 for a detailed list of how it uses the processor pins, see the BBBlue tab of my pins spreadsheet: https://goo.gl/Jkcg0w Jun 28 15:49:05 for example accelerometers, ultra sonic sensors, IR sensors, Jun 28 15:49:33 if you go to Data -> Filter Views -> By connection then you just get a list of processor IO that connect directly to external headers Jun 28 15:49:46 for all of these: it depends on the sensor and how it's interfaced Jun 28 15:50:03 the blue also has an integrated accelerometer Jun 28 15:50:21 ok cool I'll check this link out. I think I need to look up a few things about it, I need a better understanding of what these i2c buses are and do, and what the encoders do Jun 28 15:51:37 Thank you, for your help I think I'll get this. Sorry for some of the confusion, I think this answers all of my questions. Jun 28 15:51:40 they're different "protocols" of electrical signaling, and both sides need to speak the same language to understand each other ;) Jun 28 15:52:51 Ok cool! Also can I put ubuntu on this device? and I know the black has extensions like an external screen does the blue have accessories/extentions? Jun 28 15:53:21 there are also two "PRU" (programmable real-time unit) codes that can be used to implement custom protocols if one is willing to put in the effort. for example the blue uses one to implement the fourth quadrature encoder input (the hardware only has three) Jun 28 15:53:50 you could, but I would recommend against it. stick to the default debian distribution, it has the best support Jun 28 15:53:55 the blue has no video output Jun 28 15:55:36 The only reason I preference ubuntu is that ROS requires or at least strongly suggests ubuntu and I plan on using it with this. Jun 28 15:55:38 (*PRU cores, not codes... typo) Jun 28 15:57:02 ROS for packaged for debian both by ROS and by debian (see http://wiki.ros.org/UpstreamPackages for the difference) Jun 28 15:57:29 ubuntu is a derivative of debian and for something like ROS there isn't much difference between the two Jun 28 15:58:09 oh ok. I know that a lot of linux distros are debian base (as well as macs from my understanding) could see the harm in trying right? Jun 28 15:58:34 I can't parse that sentence Jun 28 15:58:43 I assume its like a computer where you can install different OS pretty easily? Jun 28 15:59:11 couldn't* Jun 28 15:59:27 *couldn't see the harm in trying right? Jun 28 15:59:52 I'll try the debian OS first with ros Jun 28 16:00:18 given that you're clearly new, it would not be smart to try to use an OS that very few people use on a particular platform, since that almost certainly means you're going to have to fix problems Jun 28 16:00:46 that seems to be the easiest idea. I think the only difference it would make is the terminal commands so I would have to find the equivalent commands from ubuntu to debian right? Jun 28 16:01:02 yes Jun 28 16:01:55 Yeah I agree with you,it would be better for me to stick to whats recommended for the beagle. Jun 28 16:04:02 I'll try to find some overview videos online I may be able to get a better visual idea of what its capabilities are. **** ENDING LOGGING AT Fri Jun 29 03:00:00 2018