wayland - weston - and framebuffer

Pekka Paalanen ppaalanen at gmail.com
Fri Mar 13 01:01:16 PDT 2015


On Thu, 12 Mar 2015 15:15:36 +0100
Thilo Cestonaro <thilo at cestona.ro> wrote:

> Hey!
> 
> I'm totaly new to wayland and weston, so please forgive me if I ask 
> silly questions!
> 
> I want to run the wayland compositor "weston" on a TI AM335x with no 
> graphic acceleration.
> So framebuffer only, no opengl or something like that.
> 
> I succeeded in compiling libwayland and weston with FBDEV as compositor 
> and the weston-tablet-shell.

Hi,

tablet-shell was removed a long long time ago as abandoned. I'd really
recommend using a more recent Weston.

If you want to try a desktop-like UX on a tablet device, just try the
(default) desktop shell. Nowdays it should mostly support
touchscreens, I think.

> Now when I try to start weston via UART connection and the command:
> 
> openvt -c 7 -w -v -- weston --tty=/dev/tty7 --device=/dev/fb0 
> --log=/home/root/weston.log
> 
> I get the following logging output:
> 
> ----------
> Date: 2015-03-12 CET
> [15:01:48.092] weston 1.3.1
>                 http://wayland.freedesktop.org/
>                 Bug reports to: 
> https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.3.1
>                 Build:
> [15:01:48.094] OS: Linux, 3.14.10, #1 SMP Wed Mar 11 10:26:14 CET 2015, 
> armv7l
> [15:01:48.100] Using config file '/home/root/.config/weston.ini'
> [15:01:48.105] Loading module '/usr/lib/weston/fbdev-backend.so'
> [15:01:48.137] initializing fbdev backend
> [15:01:48.143] Creating fbdev output.
> [15:01:48.144] Opening fbdev frame buffer.
> [15:01:48.144] Calculating pixman format from:
>                  - type: 0 (aux: 0)
>                  - visual: 2
>                  - bpp: 24 (grayscale: 0)
>                  - red: offset: 0, length: 8, MSB: 0
>                  - green: offset: 8, length: 8, MSB: 0
>                  - blue: offset: 16, length: 8, MSB: 0
>                  - transp: offset: 0, length: 0, MSB: 0
> [15:01:48.144] Mapping fbdev frame buffer.
> [15:01:48.145] fbdev output 480×272 px
>                 guessing 60 Hz and 96 dpi
> [15:01:48.151] launching '/usr/libexec/weston-keyboard'
> [15:01:48.154] input device Atmel maXTouch Touchscreen, 
> /dev/input/event1 is a touch device
> [15:01:48.161] compositor: executing '/usr/libexec/weston-keyboard' 
> failed: No such file or directory
> [15:01:48.252] input device HID 1267:0103, /dev/input/event2 is a 
> keyboard
> [15:01:48.254] input device HID 1267:0103, /dev/input/event3 is a 
> keyboard
> [15:01:48.254] input device d3355_pwrbtn_input, /dev/input/event0 is a 
> keyboard
> [15:01:48.258] Loading module '/usr/lib/weston/tablet-shell.so'
> [15:01:48.259] launching '/usr/lib/weston/weston-tablet-shell'
> [15:01:48.261] switching to state STARTING (from STARTING)
> [15:01:48.261] Compositor capabilities:
>                 arbitrary surface rotation: yes
>                 screen capture uses y-flip: yes
> [15:01:48.262] libwayland: using socket /run/user/0/wayland-0
> [15:01:48.262] INFO: befor wl_display_run
> [15:01:48.263] caught signal: 11
> [15:01:48.281] 0: weston (on_caught_signal+0x18) [0xf2ec]
> [15:01:48.284] 1: /lib/libc.so.6 (__default_rt_sa_restorer_v2+0x0) 
> [0xb6d4a998]
> [15:01:48.292] unw_get_proc_info: -10
> ----------------
> 
> For me everything looks fine! (The INFO output was added by me to look 
> if weston runs till this point)
> But why does weston then end with the SIGSEGV? Doesn't it have anything 
> to do?

Looks like a bug. Well, SEGV is always a bug somewhere. Most likely it
has been fixed a long time ago, too. You should try a recent version of
Weston.

Or, maybe __default_rt_sa_restorer_v2 hints about something strange on
your platform. The stack trace ends short, but I suppose that's normal
on ARM without debug info...

> I thought the weston-tablet-shell should be the session executable, 
> right?

weston-tablet-shell, weston-desktop-shell, and
weston-ivi-shell-user-interface are helper clients for each respective
shell module. They are executed by the weston process, which is the
only way they can work.

> Any hints how I can debug further or what I do wrong?

Use gdb like you normally do or your platform? And build libwayland and
weston with -ggdb or similar.

Does your platform have working signalfd and timerfd implementations?
Is it using glibc or something else?


Thanks,
pq


More information about the wayland-devel mailing list