Re: Weston on framebuffer?

[Pekka Paalanen]

On Thu, 21 Jul 2016 08:30:54 +0900
Carsten Haitzler (The Rasterman)  wrote:

> On Wed, 20 Jul 2016 21:49:57 +0200 Christer Weinigel 
> said:
> 

> > On the framebuffer I don't perceive any lag at all between a keypress 
> > and the character appearing on the screen.
> > 
> > With weston-terminal running I can drag the window around and even 
> > though it's not very fast and there's a bit of tearing it isn't too bad. 
> > The response when dragging feels ok.  Keypresses feel laggy even though 
> > mouse motion doesn't, but I'm not sure if that's because I don't notice 
> > the lag when moving the mouse or if it is a real difference.  
> 
> well they are done by different things. the move will be done directly by
> weston itself. it will be asked to begin a window move by the client and then
> just do it itself. render the changes. key events have a different path. they
> go to client, client handles it, draws new frame, then weston has to update
> screen with that new frame.
> 
> it seems to be either weston-terminal is just slow at drawing there and thus 
> is
> ending up taking a while to draw, add another 200ms or so for weston itself 
> and
> thats probably what's going on.

The first. I recall people saying that weston-terminal is
particularly bad at rendering performance. You might want to try a
more "serious" terminal, though I'm not sure what to suggest.

Just keeping a key pressed and looking the output of 'top' at the
same time (via a remote login or serial) should tell you what eats
the CPU if any. I would guess CPU is running at 100% and most of it
is in weston-terminal. That would confirm that weston-terminal is
just inefficient in its drawing.


Thanks,
pq


pgpBGTxJJlmfx.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston on framebuffer?

[The Rasterman]

On Wed, 20 Jul 2016 21:49:57 +0200 Christer Weinigel 
said:

> Hi,
> 
> On 07/20/2016 01:04 AM, Carsten Haitzler (The Rasterman) wrote:
> >> With this I managed to get a desktop and was unable to start
> >> wayland-terminal.  Redrawing of the graphics felt fairly snappy, but the
> >> lag from pressing a key on the keyboard until a character showed up in
> >> the terminal was slow, probably between a quarter to half a second.
> >>
> >> So my question is if this is the performance I should expect with weston
> >> on a 400MHz ARM9 and a dumb framebuffer?  Have I done something stupid
> >> and there are easy ways to speed it up?
> 
> > when you say redraw is snappy... that implies that output is fast. so time
> > from deciding to render and update and it appearing is very short. but you
> > seem to have serious input lag which implies to me that it has nothing to
> > do with your cpu speed and is something else deeper and more involved. time
> > to trace things and see how they go.
> 
> I put up a short video here:
> 
> http://zoo.weinigel.se/misc/2016-07-20-213549.webm

that's not snappy. :) startup takes quite a while. but after that moving the
terminal window around is maybe getting you 6-7fps or so.

> On the framebuffer I don't perceive any lag at all between a keypress 
> and the character appearing on the screen.
> 
> With weston-terminal running I can drag the window around and even 
> though it's not very fast and there's a bit of tearing it isn't too bad. 
> The response when dragging feels ok.  Keypresses feel laggy even though 
> mouse motion doesn't, but I'm not sure if that's because I don't notice 
> the lag when moving the mouse or if it is a real difference.

well they are done by different things. the move will be done directly by
weston itself. it will be asked to begin a window move by the client and then
just do it itself. render the changes. key events have a different path. they
go to client, client handles it, draws new frame, then weston has to update
screen with that new frame.

it seems to be either weston-terminal is just slow at drawing there and thus is
ending up taking a while to draw, add another 200ms or so for weston itself and
thats probably what's going on.

weston reads input, sends 1 or more key events to client.
client gets input now does some updates/rendering (let's say takes 200ms
assuming weston terminal is slow-ish at rendering). let's now say client sends
update buffer to weston. weston now gets it, spends 200ms rendering, then reads
buffered input, sends backto client (it may have sent it before), but weston
will be either rendering a frame (takes 200ms or a bit less) or sending events.
not both. that means at least some events could take 600ms to come back to the
screen (almost half a second) because weston got blocks then client renders,
then come back to screen. so maybe 500ms on average. half a second.

i think rendering is slow and due to the above it just adds latency to the
point where you see it easily. you only have a single cpu. any cpu time used up
one place cannot be used elsewhere. no multilpe cores. :)

that's my guess. weston is either reading input + sending, or drawing, and the
big blobs of time spent drawing mean it's not reading and sending. so that adds
UP to ~200ms THEN client gets these. client may be still drawing a previous
frame, so doesn't respond for a little bit. let's say 100ms. then client draws.
let's say 100ms, then client sends new frame over to compositor. compositor
gets frame, begins draw. now 200ms more. NOW you see what you just typed. 600ms
later. more or less. which is about what it looks like. when moving a window,
weston gets mouse events, weston redraws, repeat. so 200ms lag. speed up the
drawing or allow drawing to happen in parallel and you're good.

remember weston is the SAMPLE compositor. it will not have been tuned to run
ultra-fast on your setup. you likely have a 16bpp display but what's actually
going on is clients are rendering in 32bpp so taking longer to render that they
would natively (like the text console), and then weston is likely rendering in
32bpp too... THEN it's down-converting to 16bpp for display. none of that is
free. :) you will likely not find much support these days that doesn't involve
down-conversion as everyone is handling alpha and thus 32bpp (yes you can do
16bpp+alpha mask for example, or pack argb  into 16bpp and other
imaginative ways of getting it). dropping the whole pipeline down to something
like 16bpp+masks and a very carefully tuned pipeline would help.

(the reason i say 16bpp + masks is you can do a memcpy for the 16bpp data
direct to memory and since this doesn't convert it likely will be 2-3 times
faster - on the compositor fb side. on the client side the mask can be
pre-computed once for the window then just render 16bpp content, and with
opaque regions - since all the drawing happens inside those, the compositor can
skip blending entirely for regions 

Re: Weston on framebuffer?

[Christer Weinigel]

Hi,

On 07/20/2016 01:04 AM, Carsten Haitzler (The Rasterman) wrote:

With this I managed to get a desktop and was unable to start
wayland-terminal.  Redrawing of the graphics felt fairly snappy, but the
lag from pressing a key on the keyboard until a character showed up in
the terminal was slow, probably between a quarter to half a second.

So my question is if this is the performance I should expect with weston
on a 400MHz ARM9 and a dumb framebuffer?  Have I done something stupid
and there are easy ways to speed it up?



when you say redraw is snappy... that implies that output is fast. so time from
deciding to render and update and it appearing is very short. but you seem to
have serious input lag which implies to me that it has nothing to do with your
cpu speed and is something else deeper and more involved. time to trace things
and see how they go.


I put up a short video here:

http://zoo.weinigel.se/misc/2016-07-20-213549.webm

On the framebuffer I don't perceive any lag at all between a keypress 
and the character appearing on the screen.


With weston-terminal running I can drag the window around and even 
though it's not very fast and there's a bit of tearing it isn't too bad. 
The response when dragging feels ok.  Keypresses feel laggy even though 
mouse motion doesn't, but I'm not sure if that's because I don't notice 
the lag when moving the mouse or if it is a real difference.


I tried to do a strace of weston-terminal, but it was a bit painful, it 
reads every file it can find in /usr/share/icons/default/cursors/ when 
it starts so strace took forever before the terminal would even show up.


And for trying to do more advanced tracing, I don't quite know where to 
start.  Are there any knobs in the source to do things such as dump 
timestamps for messages between the server and client?


 /Christer
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston on framebuffer?

[The Rasterman]

On Tue, 19 Jul 2016 18:10:16 +0200 Christer Weinigel <chris...@weinigel.se>
said:

> Hi,
> 
> I'm trying to port Linux to a Samsung S3C2416 based system (actually an
> oscilloscope, http://blog.weinigel.se/2016/05/01/sds7102-hacking.html).
> 
> The S3C2416 is a 400MHz ARM9 with a fairly dumb framebuffer, it has some
> 2D acceleration (pixel/line drawing with alpha, copy rectangle with
> alpha and/or color key) but as far as I can tell nobody has added Linux
> support for it.
> 
> I'm going to need some kind of GUI for the box and somebody mentioned
> that Weston has framebuffer support nowdays.  I turned on the Weston
> config option in buildroot (2015.5) and managed to get something that
> didn't work to begin with, the OS abstraction stuff requires support for
> posix_fadvise but for some reason that didn't work with ulibc but I
> hacked around that.  libinput didn't like eudev and didn't want to
> recognize a USB keyboard and USB mouse to begin with but I just
> hardcoded the device type instead of relying on udev to tag the devices.
> 
> With this I managed to get a desktop and was unable to start
> wayland-terminal.  Redrawing of the graphics felt fairly snappy, but the
> lag from pressing a key on the keyboard until a character showed up in
> the terminal was slow, probably between a quarter to half a second.
> 
> So my question is if this is the performance I should expect with weston
> on a 400MHz ARM9 and a dumb framebuffer?  Have I done something stupid
> and there are easy ways to speed it up?
> 
> Is there any documentation on how to convert the framebuffer driver for
> the S3C2416 to a KMS driver and how to add acceleration support?  Can
> weston use this?
> 
> Or is wayland/weston not really suited for this kind of old hardware and
> what should I use in that case?
> 
>   /Christer

when you say redraw is snappy... that implies that output is fast. so time from
deciding to render and update and it appearing is very short. but you seem to
have serious input lag which implies to me that it has nothing to do with your
cpu speed and is something else deeper and more involved. time to trace things
and see how they go.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Weston on framebuffer?

[Christer Weinigel]

Hi,

I'm trying to port Linux to a Samsung S3C2416 based system (actually an
oscilloscope, http://blog.weinigel.se/2016/05/01/sds7102-hacking.html).

The S3C2416 is a 400MHz ARM9 with a fairly dumb framebuffer, it has some
2D acceleration (pixel/line drawing with alpha, copy rectangle with
alpha and/or color key) but as far as I can tell nobody has added Linux
support for it.

I'm going to need some kind of GUI for the box and somebody mentioned
that Weston has framebuffer support nowdays.  I turned on the Weston
config option in buildroot (2015.5) and managed to get something that
didn't work to begin with, the OS abstraction stuff requires support for
posix_fadvise but for some reason that didn't work with ulibc but I
hacked around that.  libinput didn't like eudev and didn't want to
recognize a USB keyboard and USB mouse to begin with but I just
hardcoded the device type instead of relying on udev to tag the devices.

With this I managed to get a desktop and was unable to start
wayland-terminal.  Redrawing of the graphics felt fairly snappy, but the
lag from pressing a key on the keyboard until a character showed up in
the terminal was slow, probably between a quarter to half a second.

So my question is if this is the performance I should expect with weston
on a 400MHz ARM9 and a dumb framebuffer?  Have I done something stupid
and there are easy ways to speed it up?

Is there any documentation on how to convert the framebuffer driver for
the S3C2416 to a KMS driver and how to add acceleration support?  Can
weston use this?

Or is wayland/weston not really suited for this kind of old hardware and
what should I use in that case?

  /Christer

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wayland - weston - and framebuffer

[Thilo Cestonaro]

Hey Pekka,

so I moved forward to 1.6.0 and fullscreen shell. But I still get the caught 
signal 11 error.

Next I will try to get to 1.7.

Any other ideas then upgrading the version?

Thx!

Regards ThiloAm 13.03.2015 09:01 schrieb Pekka Paalanen ppaala...@gmail.com:

 On Thu, 12 Mar 2015 15:15:36 +0100 
 Thilo Cestonaro th...@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=Waylandcomponent=westonversion=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 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wayland - weston - and framebuffer

[Pekka Paalanen]

On Thu, 12 Mar 2015 15:15:36 +0100
Thilo Cestonaro th...@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=Waylandcomponent=westonversion=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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wayland - weston - and framebuffer

[Thilo Cestonaro]

Hey Pekka,

1.7.0 still gets signal 11. See the log appended.
Can I somehow debug more then the output?

One thing I totally forget to mention is, that I added the pixel-format 
BGRA to fbdev to be recognized.

But as pixman already defines the type, it shouldn't be the problem.
Here is the patch which I applied:

diff -Naur a/src/compositor-fbdev.c b/src/compositor-fbdev.c
--- a/src/compositor-fbdev.c2015-03-13 09:58:04.383414803 +0100
+++ b/src/compositor-fbdev.c2015-03-13 10:03:12.167400456 +0100
@@ -295,6 +295,10 @@
 vinfo-green.offset = vinfo-blue.offset 
 vinfo-blue.offset = vinfo-transp.offset)
type = PIXMAN_TYPE_RGBA;
+   else if (vinfo-blue.offset = vinfo-green.offset 
+vinfo-green.offset = vinfo-red.offset 
+vinfo-red.offset = vinfo-transp.offset)
+   type = PIXMAN_TYPE_BGRA;

if (type == PIXMAN_TYPE_OTHER)
return 0;


And here is the output of my try to start weston:

root@d3355-BB-76-99:~# rm weston.log
root@d3355-BB-76-99:~# cat bin/start-weston
#!/bin/sh
openvt -c 7 -w -v -- weston --backend=fbdev-backend.so 
--log=/home/root/weston.log

root@d3355-BB-76-99:~# bin/start-weston
root@d3355-BB-76-99:~# cat weston.log
Date: 2015-03-13 CET
[10:49:07.470] weston 1.7.0
   http://wayland.freedesktop.org
   Bug reports to: 
https://bugs.freedesktop.org/enter_bug.cgi?product=Waylandcomponent=westonversion=1.7.0
   Build: 1.6.93-9-gdbd8606 configure.ac: bump to version 
1.7.0 for release (2015-02-13 20:47:09 -0800)
[10:49:07.471] OS: Linux, 3.14.10, #1 SMP Wed Mar 11 10:26:14 CET 2015, 
armv7l

[10:49:07.477] Using config file '/home/root/.config/weston.ini'
[10:49:07.485] Loading module '/usr/lib/weston/fbdev-backend.so'
[10:49:07.549] initializing fbdev backend
[10:49:07.556] logind: failed to get session seat
[10:49:07.557] logind: cannot setup systemd-logind helper (-2), using 
legacy fallback

[10:49:07.557] Creating fbdev output.
[10:49:07.558] Opening fbdev frame buffer.
[10:49:07.558] 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
[10:49:07.558] Mapping fbdev frame buffer.
[10:49:07.559] fbdev output 480×272 px
   guessing 60 Hz and 96 dpi
[10:49:07.568] input device 'Atmel maXTouch Touchscreen', 
/dev/input/event1 is tagged by udev as: Touchscreen
[10:49:07.568] input device 'Atmel maXTouch Touchscreen', 
/dev/input/event1 is a touch device
[10:49:07.573] input device 'HID 1267:0103', /dev/input/event2 is tagged 
by udev as: Keyboard
[10:49:07.573] input device 'HID 1267:0103', /dev/input/event2 is a 
keyboard
[10:49:07.578] input device 'HID 1267:0103', /dev/input/event3 is tagged 
by udev as: Keyboard
[10:49:07.578] input device 'HID 1267:0103', /dev/input/event3 is a 
keyboard
[10:49:07.581] input device 'd3355_pwrbtn_input', /dev/input/event0 is 
tagged by udev as: Keyboard
[10:49:07.581] input device 'd3355_pwrbtn_input', /dev/input/event0 is a 
keyboard

[10:49:07.582] launching '/usr/libexec/weston-keyboard'
[10:49:07.797] Compositor capabilities:
   arbitrary surface rotation: yes
   screen capture uses y-flip: yes
   presentation clock: CLOCK_MONOTONIC_RAW, id 4
[10:49:07.801] Loading module '/usr/lib/weston/fullscreen-shell.so'
[10:49:07.806] caught signal: 11
root@d3355-BB-76-99:~#


Regards,
Thilo

Am 13.03.2015 10:30, schrieb Thilo Cestonaro:

Hey Pekka,

so I moved forward to 1.6.0 and fullscreen shell. But I still get the
caught signal 11 error.

Next I will try to get to 1.7.

Any other ideas then upgrading the version?

Thx!

Regards ThiloAm 13.03.2015 09:01 schrieb Pekka Paalanen 
ppaala...@gmail.com:


On Thu, 12 Mar 2015 15:15:36 +0100
Thilo Cestonaro th...@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
 

Re: wayland - weston - and framebuffer

[Pekka Paalanen]

On Fri, 13 Mar 2015 10:55:38 +0100
Thilo Cestonaro th...@cestona.ro wrote:

 Hey Pekka,
 
 1.7.0 still gets signal 11. See the log appended.
 Can I somehow debug more then the output?
 
 One thing I totally forget to mention is, that I added the pixel-format 
 BGRA to fbdev to be recognized.
 But as pixman already defines the type, it shouldn't be the problem.
 Here is the patch which I applied:
 
 diff -Naur a/src/compositor-fbdev.c b/src/compositor-fbdev.c
 --- a/src/compositor-fbdev.c  2015-03-13 09:58:04.383414803 +0100
 +++ b/src/compositor-fbdev.c  2015-03-13 10:03:12.167400456 +0100
 @@ -295,6 +295,10 @@
vinfo-green.offset = vinfo-blue.offset 
vinfo-blue.offset = vinfo-transp.offset)
   type = PIXMAN_TYPE_RGBA;
 + else if (vinfo-blue.offset = vinfo-green.offset 
 +  vinfo-green.offset = vinfo-red.offset 
 +  vinfo-red.offset = vinfo-transp.offset)
 + type = PIXMAN_TYPE_BGRA;

Can't immediately imagine that being a problem.

 
   if (type == PIXMAN_TYPE_OTHER)
   return 0;
 
 
 And here is the output of my try to start weston:
 
 root@d3355-BB-76-99:~# rm weston.log
 root@d3355-BB-76-99:~# cat bin/start-weston
 #!/bin/sh
 openvt -c 7 -w -v -- weston --backend=fbdev-backend.so 
 --log=/home/root/weston.log
 root@d3355-BB-76-99:~# bin/start-weston
 root@d3355-BB-76-99:~# cat weston.log
 Date: 2015-03-13 CET
 [10:49:07.470] weston 1.7.0
 http://wayland.freedesktop.org
 Bug reports to: 
 https://bugs.freedesktop.org/enter_bug.cgi?product=Waylandcomponent=westonversion=1.7.0
 Build: 1.6.93-9-gdbd8606 configure.ac: bump to version 
 1.7.0 for release (2015-02-13 20:47:09 -0800)
 [10:49:07.471] OS: Linux, 3.14.10, #1 SMP Wed Mar 11 10:26:14 CET 2015, 
 armv7l
 [10:49:07.477] Using config file '/home/root/.config/weston.ini'
 [10:49:07.485] Loading module '/usr/lib/weston/fbdev-backend.so'
 [10:49:07.549] initializing fbdev backend
 [10:49:07.556] logind: failed to get session seat
 [10:49:07.557] logind: cannot setup systemd-logind helper (-2), using 
 legacy fallback
 [10:49:07.557] Creating fbdev output.
 [10:49:07.558] Opening fbdev frame buffer.
 [10:49:07.558] 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
 [10:49:07.558] Mapping fbdev frame buffer.
 [10:49:07.559] fbdev output 480×272 px
 guessing 60 Hz and 96 dpi
 [10:49:07.568] input device 'Atmel maXTouch Touchscreen', 
 /dev/input/event1 is tagged by udev as: Touchscreen
 [10:49:07.568] input device 'Atmel maXTouch Touchscreen', 
 /dev/input/event1 is a touch device
 [10:49:07.573] input device 'HID 1267:0103', /dev/input/event2 is tagged 
 by udev as: Keyboard
 [10:49:07.573] input device 'HID 1267:0103', /dev/input/event2 is a 
 keyboard
 [10:49:07.578] input device 'HID 1267:0103', /dev/input/event3 is tagged 
 by udev as: Keyboard
 [10:49:07.578] input device 'HID 1267:0103', /dev/input/event3 is a 
 keyboard
 [10:49:07.581] input device 'd3355_pwrbtn_input', /dev/input/event0 is 
 tagged by udev as: Keyboard
 [10:49:07.581] input device 'd3355_pwrbtn_input', /dev/input/event0 is a 
 keyboard
 [10:49:07.582] launching '/usr/libexec/weston-keyboard'
 [10:49:07.797] Compositor capabilities:
 arbitrary surface rotation: yes
 screen capture uses y-flip: yes
 presentation clock: CLOCK_MONOTONIC_RAW, id 4
 [10:49:07.801] Loading module '/usr/lib/weston/fullscreen-shell.so'
 [10:49:07.806] caught signal: 11
 root@d3355-BB-76-99:~#

Why are you trying everything else except desktop shell?

Fullscreen shell is intended mainly for running another compositor
under Weston, and the protocol is incompatible with normal (desktop)
apps. Fullscreen shell also does not show anything by default, so you'd
be looking at a black screen if it worked, IIRC.

If you don't know how to use gdb on your platform to get a proper stack
trace, there is nothing we can do for you.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wayland - weston - and framebuffer

[Thilo Cestonaro]

Hey Pekka,

thank you!

In the end it was my patch which killed it. BGRA was the wrong format as 
it uses 8Bit length for transparent channel.

I need to use ABGR which is B8G8R8A0 :). now

Regards,
Thilo


Am 13.03.2015 11:54, schrieb Pekka Paalanen:

On Fri, 13 Mar 2015 10:55:38 +0100
Thilo Cestonaro th...@cestona.ro wrote:


Hey Pekka,

1.7.0 still gets signal 11. See the log appended.
Can I somehow debug more then the output?

One thing I totally forget to mention is, that I added the 
pixel-format

BGRA to fbdev to be recognized.
But as pixman already defines the type, it shouldn't be the problem.
Here is the patch which I applied:

diff -Naur a/src/compositor-fbdev.c b/src/compositor-fbdev.c
--- a/src/compositor-fbdev.c2015-03-13 09:58:04.383414803 +0100
+++ b/src/compositor-fbdev.c2015-03-13 10:03:12.167400456 +0100
@@ -295,6 +295,10 @@
 vinfo-green.offset = vinfo-blue.offset 
 vinfo-blue.offset = vinfo-transp.offset)
type = PIXMAN_TYPE_RGBA;
+   else if (vinfo-blue.offset = vinfo-green.offset 
+vinfo-green.offset = vinfo-red.offset 
+vinfo-red.offset = vinfo-transp.offset)
+   type = PIXMAN_TYPE_BGRA;


Can't immediately imagine that being a problem.



if (type == PIXMAN_TYPE_OTHER)
return 0;


And here is the output of my try to start weston:

root@d3355-BB-76-99:~# rm weston.log
root@d3355-BB-76-99:~# cat bin/start-weston
#!/bin/sh
openvt -c 7 -w -v -- weston --backend=fbdev-backend.so
--log=/home/root/weston.log
root@d3355-BB-76-99:~# bin/start-weston
root@d3355-BB-76-99:~# cat weston.log
Date: 2015-03-13 CET
[10:49:07.470] weston 1.7.0
http://wayland.freedesktop.org
Bug reports to:
https://bugs.freedesktop.org/enter_bug.cgi?product=Waylandcomponent=westonversion=1.7.0
Build: 1.6.93-9-gdbd8606 configure.ac: bump to version
1.7.0 for release (2015-02-13 20:47:09 -0800)
[10:49:07.471] OS: Linux, 3.14.10, #1 SMP Wed Mar 11 10:26:14 CET 
2015,

armv7l
[10:49:07.477] Using config file '/home/root/.config/weston.ini'
[10:49:07.485] Loading module '/usr/lib/weston/fbdev-backend.so'
[10:49:07.549] initializing fbdev backend
[10:49:07.556] logind: failed to get session seat
[10:49:07.557] logind: cannot setup systemd-logind helper (-2), using
legacy fallback
[10:49:07.557] Creating fbdev output.
[10:49:07.558] Opening fbdev frame buffer.
[10:49:07.558] 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
[10:49:07.558] Mapping fbdev frame buffer.
[10:49:07.559] fbdev output 480×272 px
guessing 60 Hz and 96 dpi
[10:49:07.568] input device 'Atmel maXTouch Touchscreen',
/dev/input/event1 is tagged by udev as: Touchscreen
[10:49:07.568] input device 'Atmel maXTouch Touchscreen',
/dev/input/event1 is a touch device
[10:49:07.573] input device 'HID 1267:0103', /dev/input/event2 is 
tagged

by udev as: Keyboard
[10:49:07.573] input device 'HID 1267:0103', /dev/input/event2 is a
keyboard
[10:49:07.578] input device 'HID 1267:0103', /dev/input/event3 is 
tagged

by udev as: Keyboard
[10:49:07.578] input device 'HID 1267:0103', /dev/input/event3 is a
keyboard
[10:49:07.581] input device 'd3355_pwrbtn_input', /dev/input/event0 is
tagged by udev as: Keyboard
[10:49:07.581] input device 'd3355_pwrbtn_input', /dev/input/event0 is 
a

keyboard
[10:49:07.582] launching '/usr/libexec/weston-keyboard'
[10:49:07.797] Compositor capabilities:
arbitrary surface rotation: yes
screen capture uses y-flip: yes
presentation clock: CLOCK_MONOTONIC_RAW, id 4
[10:49:07.801] Loading module '/usr/lib/weston/fullscreen-shell.so'
[10:49:07.806] caught signal: 11
root@d3355-BB-76-99:~#


Why are you trying everything else except desktop shell?

Fullscreen shell is intended mainly for running another compositor
under Weston, and the protocol is incompatible with normal (desktop)
apps. Fullscreen shell also does not show anything by default, so you'd
be looking at a black screen if it worked, IIRC.

If you don't know how to use gdb on your platform to get a proper stack
trace, there is nothing we can do for you.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

wayland - weston - and framebuffer

[Thilo Cestonaro]

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.


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=Waylandcomponent=westonversion=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?
I thought the weston-tablet-shell should be the session executable, 
right?


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

I appended the weston.ini which is placed in /home/root/.config/

Any help is appreciated!

Regards!

Thilo
[core]
shell=tablet-shell.so

[shell]
background-image=/usr/share/backgrounds/gnome/Aqua.jpg
background-color=0xff002244
background-type=tile
panel-color=0x90ff
locking=true
animation=zoom
startup-animation=fade
#binding-modifier=ctrl
#num-workspaces=6
#cursor-theme=whiteglass
#cursor-size=24

#lockscreen-icon=/usr/share/icons/gnome/256x256/actions/lock.png
#lockscreen=/usr/share/backgrounds/gnome/Garden.jpg
#homescreen=/usr/share/backgrounds/gnome/Blinds.jpg
#animation=fade

[launcher]
icon=/usr/share/icons/gnome/24x24/apps/utilities-terminal.png
path=/usr/bin/gnome-terminal

[launcher]
icon=/usr/share/icons/gnome/24x24/apps/utilities-terminal.png
path=/usr/bin/weston-terminal

[launcher]
icon=/usr/share/icons/hicolor/24x24/apps/google-chrome.png
path=/usr/bin/google-chrome

[launcher]
icon=/usr/share/icons/gnome/24x24/apps/arts.png
path=./clients/weston-flower

[screensaver]
# Uncomment path to disable screensaver
path=/usr/libexec/weston-screensaver
duration=600

[input-method]
path=/usr/libexec/weston-keyboard

#[output]
#name=LVDS1
#mode=1680x1050
#transform=90
#icc_profile=/usr/share/color/icc/colord/Bluish.icc

#[output]
#name=VGA1
#mode=173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
#transform=flipped

#[output]
#name=X1
#mode=1024x768
#transform=flipped-270

#[touchpad]
#constant_accel_factor = 50
#min_accel_factor = 0.16
#max_accel_factor = 1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel