/dev/fb0 imx8 plus

seasoned_geek · October 24, 2021, 9:42pm

This should have been falling off a log simple, but I’ve burned about a day and a half on it. Time to send up a flare.

Just trying to get the HostMonitor demo for GuiLite running on my iMX8 Plus and Verdin full size carrier board. I mean this demo and library runs just about everywhere. On the Pi and other ARM devices it just opens and uses /dev/fb0 for output.

This is an incredibly tiny UI library and it doesn’t try to do anything kinky.

I’ve searched on here for /dev/fb0 but there are just too many hits to track down.
According to this doc I should be able to use /dev/fb.

My memory is not completely gone, /dev/fb0 should work according to this doc as well.
https://www.kernel.org/doc/html/latest/fb/framebuffer.html

This conversation looked promising but proved fruitless for me.

I made the mistake of thinking and looking for documentation on weston.ini. Could not find it on Toradex site. Found it no Ubuntu which is also Debian based.

http://manpages.ubuntu.com/manpages/bionic/man5/weston.ini.5.html

That lead me thinking I needed to add some backend support. Kind of bolstered via this message thread.

Found out the hard way if you put any of those in the ini file, you do not start.

developer@KneeVoice-developer-VirtualBox:~/Projects/GuiLiteHost$ cat Dockerfile

FROM --platform=linux/arm64/v8 torizon/weston-vivante:2

ADD HostMonitor /home/torizon/
ADD .sync_data.sh /home/torizon/
ADD icons8-system-task-48.png /home/torizon/
COPY weston.ini /etc/xdg/weston/
COPY weston.ini /etc/xdg/weston-dev/

ADD launch-host-monitor /home/torizon/

weston.ini

[core]
idle-time=0
require-input=false
xwayland=true
modules=screen-share.so

[libinput]
enable_tap=true

[shell]
background-image=
background-color=0x65FFEA80
panel-position=top
locking=false
allow-zap=false
num-workspaces=1


[keyboard]
vt-switching=false


[launcher]
icon=/home/torizon/icons8-system-task-48.png
path=/home/torizon/launch-host-monitor

launch-host-monitor

#! /bin/bash
cd /home/torizon
./HostMonitor /dev/fb0

docker run -e ACCEPT_FSL_EULA=1 -it --rm --name=barney --net=host --cap-add CAP_SYS_TTY_CONFIG \
             -v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/ \
             --device-cgroup-rule='c 4:* rmw' --device-cgroup-rule='c 13:* rmw' \
             --device-cgroup-rule='c 199:* rmw' --device-cgroup-rule='c 226:* rmw' \
             seasonedgeek/gl-hostmonitor

The little icon shows up on the screen like one would expect.

Try to run and “open fb failed!”
: Operation not permitted

I assume there is some dark magic needed on the docker run invocation that is not found within an hour of searching the Toradex site. If you could tell me what that dark magic is I would appreciate it.

Just how is an application supposed to access the frame buffer? Every straight forward method I have tried has failed on this platform.

seasoned_geek · October 25, 2021, 8:02pm

The short answer is you have to ignore all things weston.

docker run -e ACCEPT_FSL_EULA=1 -d --privileged --rm --name=wayland-app --user=torizon
-v /dev/dri:/dev/dri -v /dev/galcore:/dev/galcore -v /tmp:/tmp
–device-cgroup-rule=‘c 199:* rmw’ --device-cgroup-rule=‘c 226:* rmw’
seasonedgeek/gl-hostmonitor launch-host-monitor

As long as you don’t have a 7 inch chalkboard this will work fine, just won’t have mouse or touch.

Chalkboard will be posted as different question

jeremias.tx · October 25, 2021, 8:25pm

Hi @seasoned_geek,

I was in the middle of writing a reply but I see you have already sorted things out here.

If you’re working with the /dev/fb0 directly like this then I would forgo Weston/Wayland as you’ve done. Just to avoid any unnecessary complications.

Just some additional comments that may help. Technically the direct framebuffer driver is not supported for the i.MX8* platforms via NXP. The graphical stack instead uses the DRM/KMS system. However NXP does provide a legacy interface /dev/fb0, so you “should” be fine but keep this in mind if you see anything strange when working with /dev/fb0.

Also I see you added --privileged to your docker command to get around the permission issue you had initially. This is fine, just be aware that this essentially gives that specific container root privileges. If you want a more nuanced permissions setting you can try adding a new cgroup rule for the /dev/fb0 interface. See here for reference: linux/devices.txt at master · torvalds/linux · GitHub

Best Regards,
Jeremias

seasoned_geek · October 27, 2021, 1:36pm

Thanks,

I only have half a solution. I don’t have the actual touchscreen though so I don’t know just how deep to dive. It’s not even certain GuiLite will be the UI library right now. This was more of a proof of concept “does it run on this board.” Without the weston stuff or X11 would have to jump through some hoops for touchscreen support.

I built one container from
FROM --platform=linux/arm64/v8 torizon/debian:2-bullseye

and got that as well. Chalkboard has an odd “default” resolutions of 1280x800@60. It can adapt to some other resolutions but unlike the bulk of today’s desktop monitors it doesn’t auto-adapt to whatever resolution the video card wants to feed.

I’m really just responding now so someone else doesn’t have to burn two days of their life going down a rabbit hole that should have been a lot shorter.

Personally I find it hilarious that /dev/fb0 frame buffer writing is frowned on, yet the new world order has a frame buffer.
https://www.kernel.org/doc/html/v4.17/gpu/drm-kms.html

struct drm_mode_config_funcs {
  struct drm_framebuffer *(*fb_create)(struct drm_device *dev,struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);
  const struct drm_format_info *(*get_format_info)(const struct drm_mode_fb_cmd2 *mode_cmd);
  void (*output_poll_changed)(struct drm_device *dev);
  enum drm_mode_status (*mode_valid)(struct drm_device *dev, const struct drm_display_mode *mode);
  int (*atomic_check)(struct drm_device *dev, struct drm_atomic_state *state);
  int (*atomic_commit)(struct drm_device *dev,struct drm_atomic_state *state, bool nonblock);
  struct drm_atomic_state *(*atomic_state_alloc)(struct drm_device *dev);
  void (*atomic_state_clear)(struct drm_atomic_state *state);
  void (*atomic_state_free)(struct drm_atomic_state *state);
};

they just call it drm_framebuffer.

Push comes to shove the tiny section of code that actually communicates with the frame buffer could be updated to behave in a manner more consistent with the new world order.

Quite a few blog posts on how to get to the new new new frame buffer.

http://betteros.org/tut/graphics1.php#dumb

jeremias.tx · October 27, 2021, 6:45pm

Regarding the display resolution and the touchscreen. Just to double-check what kind of display interface does that display use? (HDMI, LVDS, etc.). Also what interface is the touchscreen? (USB, I2C, etc.).

Just wondering since depending on the interfaces this may require device tree level changes to support the hardware properly.

Best Regards,
Jeremias

seasoned_geek · October 28, 2021, 3:17pm

Sorry for the delayed response.

Chalkboard uses a USB connection for the touch screen expecting it to be treated as a mouse or something. They do have multi-touch so possibly a custom driver.

Mine is a 7 inch and is left over from a Raspberry Pi project I did some years ago. On the Pi (I forget what gen) it “just worked” under Raspian.
https://chalk-elec.com/

This is not the touchscreen the final product will have. That will have a 10 inch and I currently have no idea where it is coming from. That’s something for the hardware team to deal with.

If the Weston container is running, or if Portainer is running the 7 inch is fine. Everything scales and looks like one would expect.

The touchscreen doesn’t currently function, but I have exerted zero effort there. Yes, I’ve seen the snippets I can add to weston.ini to enable and calibrate a touchscreen, it just hasn’t been a priority.

Amazing how much those prices have come down! I think mine was around $500 at the time I bought it. I would expect more and more projects will use one of these for development now that they are under $150.

Honestly, I’m certain that as long as one is running under Weston it will be fine. It has been my experience that raw frame buffer writes need a monitor that auto-adapts to whatever “standard VGA” resolution is baked into the hardware.

Thank you for your assistance.

jeremias.tx · October 28, 2021, 9:18pm

Interesting display you have that is indeed useful for testing/development. With regards to the USB touch, unfortunately all the USB touch displays I have “just work” out of the box. But you’re probably right about there being some specific driver needed here.

In any case like you said this won’t be the final display for the customer so probably best not to spend too much time on minor details.

Glad you were able to progress!

Best Regards,
Jeremias