Re: [PATCH]: mtdev could be disabled at configuration
On Mon, Jun 10, 2013 at 8:42 AM, Pekka Paalanen wrote: > On Fri, 7 Jun 2013 12:11:14 +0200 > Marc Chalain wrote: > >> mtdev is not necessary on some device (desktop or set-top-box). For >> embedded solution the minimum of dependencies is required. "configure" >> accepts the --disable-mtdev option. > > Hi Marc, > > with this patch, if weston is compiled with --disable-mtdev, it looks > like it will still happily open multitouch devices, expose them to > Wayland clients, and feed them garbage or fail or whatever. Right? Hi Pekka, no. mtdev is a compatibility layer for converting very rare touchscreen using the multitouch protocol A into the mostly used multitouch protocol B. To my mind, only legacy devices (ntrig 0001 and few others) use the protocol A. So without mtdev, wayland will open and handle most of the multitouch screen happily. > > I think the proper approach is to change the configure option into > --disable-multitouch or --disable-touchscreen, which would not only > drop the dependency to mtdev, but also make Weston ignore all > touchscreen devices since it will not be able to handle them. Without mtdev, wayland should only ignore multitouch screen not presenting the ABS_MT_SLOT axis. Those relying on SYN_MT_REPORT do not provide tracking (which is done by mtdev). So my guess is that if you detect multitouch screens by looking at ABS_MT_SLOT, then everything will be fine whether or not you have mtdev: - multitouch B screens will correctly be handled - multitouch A screens will be processed as a single touch screen, which is not a problem because the kernel provides single touch emulation since the early days of multitouch. And if mtdev is present, then it will show the ABS_MT_SLOT axis, leading to the previous case. Bonus point, mtdev has not been updated since a long time, and is missing the bits allowing you to retrieve the initial per-slot states. And you may find useful to retrieve the current states when weston launches. Cheers, Benjamin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The way to use system cursor and custom(client) cursor
On Mon, 10 Jun 2013 10:52:34 -0700 Elvis Lee(이광웅) wrote: > > -Original Message- > > From: wayland-devel-bounces+kwangwoong.lee=lge@lists.freedesktop.org > > [mailto:wayland-devel-bounces+kwangwoong.lee=lge@lists.freedesktop.org] > > On Behalf Of Pekka Paalanen > > Sent: Sunday, June 09, 2013 11:03 PM > > To: Elvis Lee (__) > > Cc: wayland-devel@lists.freedesktop.org > > Subject: Re: The way to use system cursor and custom(client) cursor > > > > On Sun, 9 Jun 2013 16:01:48 -0700 > > Elvis Lee(__) wrote: > > > > > Hello. > > > > > > > > > > > > I feel unnatural to implement custom cursor scenario. Here is a question. > > > > > > How does a client request compositor to use system cursor? > > > > > > > > > > > > The system cursor means a current default cursor for compositor. > > > > > > Currently, client should know about the system cursor in order to use > > > it as parameter of wl_pointer.set_cursor. > > > > > > Otherwise, cursor surface should be destroyed to request compositor a > > > rollback to system cursor from custom cursor. > > > > > > > > > > > > I think it¡¯s enough to detach buffer from cursor surface for hiding > > > the cursor. > > > > > > And set_cursor(null surface) can be used to request to stop using > > > custom cursor. (rollback) > > > > > > > > > > > > Here are some states and protocols. > > > > > > > > > > > > 1. System cursor -> Custom cursor > > > > > > A. set_cursor(cursor_surface) > > > > > > B. cursor_surface.attach(buffer for custom image) > > > > > > C. cursor_surface.damage > > > > > > D. cursor_surface.commit > > > > > > > > > > > > 2. Custom cursor -> System cursor > > > > > > A. set_cursor(null surface) > > > > > > > > > > > > 3. Custom cursor -> Hide Cursor > > > > > > A. set_cursor(cursor_surface) (can be omitted if it is already set) > > > > > > B. cursor_surface.attach(null buffer) > > > > > > C. cursor_surface.commit > > > > > > > > > > > > 4. System cursor -> Hide Cursor > > > > > > A. set_cursor(cursor_surface) > > > > > > B. cursor_surface.attach(null buffer) (can be omitted if it is > > already > > > detached) > > > > > > C. cursor_surface.commit > > > > > > > > > > > > I think this can cover up a scenario when pointer enters into a > > > surface of client. > > > > > > If there is no specific cursor for client to want when pointer enters, > > > it¡¯s enough to request set_cursor(null). > > > > > > > > > > > > Is this approach possible? I want to listen your opinions. > > > > Hi Elvis, > > > > do I understand right, that you would like to add the concept of a system > > cursor? > > > > I guess it would be possible, but why? > > > > It seems the system cursor you propose would be one arbitrary cursor > > without any meaning. When and why would applications ever want to use it? > > > > The compositor usually cannot, and there is no need to, switch to a system > > cursor on its own, so it would always be requested by a client. > > I can understand applications wanting a specific cursor, or no cursor, but > > what would be the purpose of a system cursor? > > > > If you also consider cursor themes, the system cursor would be from one > > theme. An application using a system cursor would need to use the same > > theme for its other cursors to look consistent. > > > > We already have libwayland-cursor to help you load a cursor theme, so > > using a proper cursor should not be too hard. > > > > Hi, Pekka. > > Thanks for your opinion. > > Possibly, The word 'system cursor' can attract over attention. > As you said, it's just one of the cursor themes. > > > It might be unclear for my explain. Here is a simple scenario. > Compositor can own its cursor without client or with minimized client or > outside focused client window. > And the cursor is configurable. > Compositor stared with blue cursor, then user changes it to red one. > After launching a client, the client override the cursor with specific one. > After a while, client want to use the cursor which is used by compositor just > before. What do you mean by the compositor's cursor? Like krh explained to Bill, in Weston, there are no noticeable surfaces owned by the compositor. Everything, including the background color fill, are owned by some client. That client gets pointer enter events and sets the cursor on enter, as any client does. A scenario or screen areas without *any* clients is a bug in Weston's world. However, for embedded, I guess it can be useful for the compositor to use a hardware color fill as the background, e.g. to save memory. In that case, the compositor needs to mimic the behaviour of a client providing that background: generate internal pointer enter events and set the cursor, when the pointer enters compositor-owned area. The compositor itself could probably be using libwayland-cursor to load the default cursor theme. (If this is not possible with the current libwayland-cursor, I believe
Re: [PATCH weston v2 4/4] weston.pc: Provide moduledir
On 10/06/2013 18:23, Othman, Ossama wrote: Hi, --- a/src/Makefile.am +++ b/src/Makefile.am @@ -94,7 +94,6 @@ westoninclude_HEADERS = \ ../shared/matrix.h \ ../shared/config-parser.h -moduledir = $(libdir)/weston module_LTLIBRARIES = \ On a related note, any idea why Weston doesn't use Automake's pkglib prefix? The corresponding pkglibdir variable ends up having the same value. Is it just a convention/clarity thing? I realize Autoconf doesn't support pkglibdir without help. The point of having moduledir is that we may use e.g. $(pkglibdir)/modules if weston shipped a real package-wide libraries. libtoytoolkit and libshared would be in $(pkglib) if they were not static libraries (and having them static is good enough since they have only a few installed customers each). But in this regard, we may set moduledir to $(pkglibdir) for now, or directly to $(pkglibdir)/modules. I will send a patch or two on this directories’ thing. Thanks for the comment. -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] weston.pc: Added libexecdir and pkglibexecdir variables
On 11/06/2013 08:05, Pekka Paalanen wrote: On Mon, 10 Jun 2013 14:40:19 -0300 "Eduardo Lima (Etrunko)" wrote: I have added the pkglibexedir in an attempt to avoid crowding libexecdir too much. Other than that, no special reason. Ok, so should the weston install paths be adjusted to pkglibexecdir? Could you write a patch for that? I think it might be a good idea. I can include it in a series to clean and move a few stuff around to “more standard paths” if you want. -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH]: mtdev could be disabled at configuration
On Tue, 11 Jun 2013 09:01:48 +0200 Benjamin Tissoires wrote: > On Mon, Jun 10, 2013 at 8:42 AM, Pekka Paalanen wrote: > > On Fri, 7 Jun 2013 12:11:14 +0200 > > Marc Chalain wrote: > > > >> mtdev is not necessary on some device (desktop or set-top-box). For > >> embedded solution the minimum of dependencies is required. "configure" > >> accepts the --disable-mtdev option. > > > > Hi Marc, > > > > with this patch, if weston is compiled with --disable-mtdev, it looks > > like it will still happily open multitouch devices, expose them to > > Wayland clients, and feed them garbage or fail or whatever. Right? > > Hi Pekka, > > no. mtdev is a compatibility layer for converting very rare > touchscreen using the multitouch protocol A into the mostly used > multitouch protocol B. > To my mind, only legacy devices (ntrig 0001 and few others) use the protocol > A. > So without mtdev, wayland will open and handle most of the multitouch > screen happily. > > > > > I think the proper approach is to change the configure option into > > --disable-multitouch or --disable-touchscreen, which would not only > > drop the dependency to mtdev, but also make Weston ignore all > > touchscreen devices since it will not be able to handle them. > > Without mtdev, wayland should only ignore multitouch screen not > presenting the ABS_MT_SLOT axis. > Those relying on SYN_MT_REPORT do not provide tracking (which is done by > mtdev). > > So my guess is that if you detect multitouch screens by looking at > ABS_MT_SLOT, then everything will be fine whether or not you have > mtdev: > - multitouch B screens will correctly be handled > - multitouch A screens will be processed as a single touch screen, > which is not a problem because the kernel provides single touch > emulation since the early days of multitouch. And if mtdev is present, > then it will show the ABS_MT_SLOT axis, leading to the previous case. > > Bonus point, mtdev has not been updated since a long time, and is > missing the bits allowing you to retrieve the initial per-slot states. > And you may find useful to retrieve the current states when weston > launches. Thank you for clarifying that, Benjamin. Does this mean that we need explicit single-touch support in Weston? I don't think we have that yet. Everything touchy goes through mtdev, which makes also real single-touch devices look like multitouch devices except they never report more than one contact. Do I understand that right? Marc, in any case, I think you should check that Weston correctly ignores touch devices it cannot support without mtdev, as per Benjamin's instructions above. Retrieving current state is a matter for another time. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ISSUE] shadow buffer not copied inside the frame buffer
Hi,
Since Monday, my screen is black. I make test and when I write some colors
directly inside the frame buffer, they appear.
To be clearer I added inside fbdev_output_repaint
{
unsigned short color=0xA55A;
int i;
for (i = 0; i < output->fb_info.buffer_length / 2; i+=2)
{
*(unsigned short *)(output->fb + i) = color + i;
}
}
and the display is painted, but without the shadow_buffer and the screen
are black.
Has somebody an idea ?
Marc.
PS: I can't continue with this issue.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [ISSUE] shadow buffer not copied inside the frame buffer
Hello
Then when I start weston with:
--backend=fbdev-backend.so --modules=tablet-shell.so --device=/dev/fb0
desktop-shell.so and tablet-shell.so seem to be started in the same time
and tablet-shell.so cover some parts of desktop-shell.so.
if I start weston with:
--backend=fbdev-backend.so --device=/dev/fb0
and inside weston.ini with:
[core]
modules=tablet-shell.so
[shell]
homescreen=
The background (homescreen) flashes and the screen becomes black.
Then I suppose that tablet-shell.so is buggy first and the mix of two
shells is not recommended.
When I start weston with only the desktop-shell.so, it seems to work.
One day and an half loose.
Marc.
2013/6/11 Marc Chalain
> Hi,
> Since Monday, my screen is black. I make test and when I write some colors
> directly inside the frame buffer, they appear.
> To be clearer I added inside fbdev_output_repaint
> {
> unsigned short color=0xA55A;
> int i;
> for (i = 0; i < output->fb_info.buffer_length / 2; i+=2)
> {
> *(unsigned short *)(output->fb + i) = color + i;
> }
> }
> and the display is painted, but without the shadow_buffer and the screen
> are black.
>
> Has somebody an idea ?
> Marc.
>
> PS: I can't continue with this issue.
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor for eink device
On Tue, 11 Jun 2013 08:44:15 +0200 Claudius Marpa Heine wrote: > Hi folks, > > for my master thesis in computer science I am looking into implementing > a wayland-compositor for eink devices (specifically for a Kobo Glo > Reader I own). For the record I am currently only looking into it, so > no promises ;) Hi Claudius, that is a very cool idea for a project! > Someone from the mobileread forum already implemented a open source java > replacement for the environment [1]. He used the native einkfb library > [2] to write into the eink framebuffer. Ok, looks like fbdev with some extended ioctls. > I would like to have a "normal" compositor and shell to be able to run > gtk or qt applications on the eink device. I already looked over the > weston code and I think that all I have to do is to make a fork of > framebuffer compositor where I add eink support and to implement a > tablet shell for this device class. Yes, starting from compositor-fbdev.c is the way to go. Note, that if you go with tablet-shell, then all toolkits need to specifically have support for it. An initially easier route would be to bend the desktop-shell to work on the device, though I guess it might not be a good match for the user interface paradigm. So I suggest starting with desktop-shell, and seeing what you need to break to make the UI nice and usable. > I don't have experience in this field (eink and compositors), but here > are some issues I am currently thinking of: > 1. eink display should only repaint if something changed and only with a > limited fps (if someone get the crazy idea to watch videos with it) > 2. repainting should only happen to the area/pixels that changed and > every x times repainting the whole display. Weston already has infrastructure in place to both repaint only the damage, and to throttle the framerate all the way down to clients. In your backend, you can force a full repaint as needed, I think. You may want to look into the pixman renderer and fbdev backend for more details. I looked at the einkfb code, and it seems the wait for screen update to complete is blocking. That is not too good, since it would block the whole compositor. You may need to put that ioctl into a separate thread to have it run async, and then signal the completion. For an example of how to handle a completion function call from a different thread, see the flippipe code in compositor-rpi.c. If you can get an event via the device file descriptor, making the fd readable when the screen update has completed, that would integrate well with the main loop in weston. If not, you need the flippipe relay. > 3. There are many different eink devices with out there. Is there a > possibility to write an abstraction layer? Don't write an abstraction layer as the first thing. When we get the third different eink driver for weston, then it becomes possible to see if an abstraction could be designed, or if they only want some helpers for the common code. Ideally, there would be DRM/KMS drivers for all eink displays, so a user space abstraction would not be needed. How feasible that is, I do not know, and I think it would also be out of scope for your thesis. (DRM/KMS drivers do not *have to* support acceleration, I believe they could be written to support only dumb buffers, which are generic.) > When rendering works I would start working on a tablet shell. > > Do you have some constructive comments/ideas? Is the input exposed as standard evdev input devices? Is there udev? > Do you think this idea is realizable within a master thesis for a > beginner like me? I assume you are fluent in C and familiar with programming on GNU/Linux. Hmm, master's thesis, i.e. 6 months of work including the literary work and writing the thesis. I would say with desktop-shell, no problem. Continuing to tablet-shell may be more work than you expect due to the client support required. But, the tablet-shell part could rely on the toy demos, and show what is possible, even if it does not run gtk and Qt apps. We have been craving for a good example of a completely different shell than the desktop oriented ones, to make a point of what shells actually are supposed to be. If you could make that point, that would be brilliant! Ah, and another note: the current desktop-shell does not react to touch input at all. You may need to pick which way to go, since doing both desktop shell with touch and a tablet shell is probably too much. > [1] http://www.mobileread.com/forums/showthread.php?t=196994 > [2] https://mediaz.googlecode.com/svn/trunk/ReaderZ/native/einkfb/ If you like Qt, I think it might be possible to use only Qt to write an eink compositor, but I don't know much about that. Depends on your goals, too. Cheers, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [ISSUE] shadow buffer not copied inside the frame buffer
On Tue, 11 Jun 2013 11:29:30 +0200 Marc Chalain wrote: > Hello > Then when I start weston with: > --backend=fbdev-backend.so --modules=tablet-shell.so --device=/dev/fb0 > desktop-shell.so and tablet-shell.so seem to be started in the same time > and tablet-shell.so cover some parts of desktop-shell.so. > if I start weston with: > --backend=fbdev-backend.so --device=/dev/fb0 > and inside weston.ini with: > [core] > modules=tablet-shell.so > [shell] > homescreen= > The background (homescreen) flashes and the screen becomes black. > > Then I suppose that tablet-shell.so is buggy first and the mix of two > shells is not recommended. > > When I start weston with only the desktop-shell.so, it seems to work. Yup, only one shell at a time works, and tablet-shell has been neglected for a long time now, unfortunately. I doubt there is any client support for tablet-shell, either. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor for eink device
Guys Hi, An interesting area which I've done some work on with a kobo touch, some useful links at https://wiki.merproject.org/wiki/Community_Workspace/kobo On Tue, Jun 11, 2013 at 10:38 AM, Pekka Paalanen wrote: > On Tue, 11 Jun 2013 08:44:15 +0200 > Claudius Marpa Heine > wrote: > > > Hi folks, > > > > for my master thesis in computer science I am looking into implementing > > a wayland-compositor for eink devices (specifically for a Kobo Glo > > Reader I own). For the record I am currently only looking into it, so > > no promises ;) > > Hi Claudius, > > that is a very cool idea for a project! > > > Someone from the mobileread forum already implemented a open source java > > replacement for the environment [1]. He used the native einkfb library > > [2] to write into the eink framebuffer. > > Ok, looks like fbdev with some extended ioctls. > > > I would like to have a "normal" compositor and shell to be able to run > > gtk or qt applications on the eink device. I already looked over the > > weston code and I think that all I have to do is to make a fork of > > framebuffer compositor where I add eink support and to implement a > > tablet shell for this device class. > > Yes, starting from compositor-fbdev.c is the way to go. > > Note, that if you go with tablet-shell, then all toolkits need to > specifically have support for it. An initially easier route would be to > bend the desktop-shell to work on the device, though I guess it might > not be a good match for the user interface paradigm. So I suggest > starting with desktop-shell, and seeing what you need to break to make > the UI nice and usable. > > > I don't have experience in this field (eink and compositors), but here > > are some issues I am currently thinking of: > > 1. eink display should only repaint if something changed and only with a > > limited fps (if someone get the crazy idea to watch videos with it) > > 2. repainting should only happen to the area/pixels that changed and > > every x times repainting the whole display. > > Weston already has infrastructure in place to both repaint only the > damage, and to throttle the framerate all the way down to clients. In > your backend, you can force a full repaint as needed, I think. You may > want to look into the pixman renderer and fbdev backend for more > details. > > I looked at the einkfb code, and it seems the wait for screen update to > complete is blocking. That is not too good, since it would block the > whole compositor. You may need to put that ioctl into a separate > thread to have it run async, and then signal the completion. For an > example of how to handle a completion function call from a different > thread, see the flippipe code in compositor-rpi.c. > > If you can get an event via the device file descriptor, making the fd > readable when the screen update has completed, that would integrate > well with the main loop in weston. If not, you need the flippipe > relay. > > > 3. There are many different eink devices with out there. Is there a > > possibility to write an abstraction layer? > > Don't write an abstraction layer as the first thing. When we get the > third different eink driver for weston, then it becomes possible to > see if an abstraction could be designed, or if they only want some > helpers for the common code. > > Ideally, there would be DRM/KMS drivers for all eink displays, so a > user space abstraction would not be needed. How feasible that is, I do > not know, and I think it would also be out of scope for your thesis. > > (DRM/KMS drivers do not *have to* support acceleration, I believe they > could be written to support only dumb buffers, which are generic.) > > > When rendering works I would start working on a tablet shell. > > > > Do you have some constructive comments/ideas? > > Is the input exposed as standard evdev input devices? Is there udev? > > > Do you think this idea is realizable within a master thesis for a > > beginner like me? > > I assume you are fluent in C and familiar with programming on GNU/Linux. > > Hmm, master's thesis, i.e. 6 months of work including the literary work > and writing the thesis. I would say with desktop-shell, no problem. > Continuing to tablet-shell may be more work than you expect due to the > client support required. But, the tablet-shell part could rely on the > toy demos, and show what is possible, even if it does not run gtk and > Qt apps. > > We have been craving for a good example of a completely different > shell than the desktop oriented ones, to make a point of what shells > actually are supposed to be. If you could make that point, that would > be brilliant! > > Ah, and another note: the current desktop-shell does not react to touch > input at all. You may need to pick which way to go, since doing both > desktop shell with touch and a tablet shell is probably too much. > > > [1] http://www.mobileread.com/forums/showthread.php?t=196994 > > [2] https://mediaz.googlecode.com/svn/trunk/ReaderZ/native/einkf
Re: [PATCH] cursor in editor.c now goes to a newline
On Mon, 10 Jun 2013 22:18:12 +0200 blackwolf12333 wrote: > --- > clients/editor.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/clients/editor.c b/clients/editor.c > index d4e4e92..df82ed0 100644 > --- a/clients/editor.c > +++ b/clients/editor.c > @@ -946,8 +946,8 @@ text_entry_draw_cursor(struct text_entry *entry, cairo_t > *cr) > &cursor_pos, NULL); > > cairo_set_line_width(cr, 1.0); > - cairo_move_to(cr, PANGO_PIXELS(cursor_pos.x), > PANGO_PIXELS(extents.height) + 2); > - cairo_line_to(cr, PANGO_PIXELS(cursor_pos.x), - 2); > + cairo_move_to(cr, PANGO_PIXELS(cursor_pos.x), > PANGO_PIXELS(cursor_pos.y) + 20); > + cairo_line_to(cr, PANGO_PIXELS(cursor_pos.x), > PANGO_PIXELS(cursor_pos.y)); > cairo_stroke(cr); > } > Hi, where does the +20 come from? Is it related to font size? Could Pango tell us the proper height so it matches the font? Would it be more correct to just add cursor_pos.y in the old code? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH]: mtdev could be disabled at configuration
On Tue, Jun 11, 2013 at 9:41 AM, Pekka Paalanen wrote: > On Tue, 11 Jun 2013 09:01:48 +0200 > Benjamin Tissoires wrote: > >> On Mon, Jun 10, 2013 at 8:42 AM, Pekka Paalanen wrote: >> > On Fri, 7 Jun 2013 12:11:14 +0200 >> > Marc Chalain wrote: >> > >> >> mtdev is not necessary on some device (desktop or set-top-box). For >> >> embedded solution the minimum of dependencies is required. "configure" >> >> accepts the --disable-mtdev option. >> > >> > Hi Marc, >> > >> > with this patch, if weston is compiled with --disable-mtdev, it looks >> > like it will still happily open multitouch devices, expose them to >> > Wayland clients, and feed them garbage or fail or whatever. Right? >> >> Hi Pekka, >> >> no. mtdev is a compatibility layer for converting very rare >> touchscreen using the multitouch protocol A into the mostly used >> multitouch protocol B. >> To my mind, only legacy devices (ntrig 0001 and few others) use the protocol >> A. >> So without mtdev, wayland will open and handle most of the multitouch >> screen happily. >> >> > >> > I think the proper approach is to change the configure option into >> > --disable-multitouch or --disable-touchscreen, which would not only >> > drop the dependency to mtdev, but also make Weston ignore all >> > touchscreen devices since it will not be able to handle them. >> >> Without mtdev, wayland should only ignore multitouch screen not >> presenting the ABS_MT_SLOT axis. >> Those relying on SYN_MT_REPORT do not provide tracking (which is done by >> mtdev). >> >> So my guess is that if you detect multitouch screens by looking at >> ABS_MT_SLOT, then everything will be fine whether or not you have >> mtdev: >> - multitouch B screens will correctly be handled >> - multitouch A screens will be processed as a single touch screen, >> which is not a problem because the kernel provides single touch >> emulation since the early days of multitouch. And if mtdev is present, >> then it will show the ABS_MT_SLOT axis, leading to the previous case. >> >> Bonus point, mtdev has not been updated since a long time, and is >> missing the bits allowing you to retrieve the initial per-slot states. >> And you may find useful to retrieve the current states when weston >> launches. > > Thank you for clarifying that, Benjamin. > > Does this mean that we need explicit single-touch support in Weston? After giving a quick look at evdev.c, it appears that single touch devices are already treated in the same way tablets (with stylus) are. So, single touch devices are seen from weston in the same way they have been seen in Xorg since the beginning: as absolute input devices. Then, it's just a matter of deciding whether we want to inform the client if the source of the event is a finger or a pen. > > I don't think we have that yet. Everything touchy goes through mtdev, > which makes also real single-touch devices look like multitouch devices > except they never report more than one contact. Do I understand that > right? evdev.c detects "touch" devices by looking at ABS_MT_SLOT. But mtdev does not transform single touch device into pseudo-multitouch devices. So I would say that those single touch devices are not treated as "touch" today. > > Marc, in any case, I think you should check that Weston correctly > ignores touch devices it cannot support without mtdev, as per > Benjamin's instructions above. > > Retrieving current state is a matter for another time. > Oh yes. FYI, I still did not found the time to finalize the patches for Xorg :) Cheers, Benjamin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor for eink device
On Tue, 11 Jun 2013 10:56:49 +0100 martin brook wrote: > Guys Hi, > > An interesting area which I've done some work on with a kobo touch, some > useful links at > > https://wiki.merproject.org/wiki/Community_Workspace/kobo Ok, only static pseudocolor, of course. Hopefully that matches PIXMAN_g8 format and pixman does the conversion automatically and without too much hit. The current pixman renderer in Weston is written for ARGB compositing of client provided images. It is wasteful to first composite in ARGB and then convert to grayscale, so if that needs optimizing, you may need to: - convert incoming buffers to grayscale and maintain a copy - modify the pixman renderer to composite in grayscale+alpha, if possible - add a grayscale pixel format to wl_shm protocol (I have planned on adding more formats anyway) - modifying clients to use the grayscale format But I think it is possible to start with the pixman renderer as is, and convert to grayscale when copying to the fb. Cheers, pq > On Tue, Jun 11, 2013 at 10:38 AM, Pekka Paalanen wrote: > > > On Tue, 11 Jun 2013 08:44:15 +0200 > > Claudius Marpa Heine > > wrote: > > > > > Hi folks, > > > > > > for my master thesis in computer science I am looking into implementing > > > a wayland-compositor for eink devices (specifically for a Kobo Glo > > > Reader I own). For the record I am currently only looking into it, so > > > no promises ;) > > > > Hi Claudius, > > > > that is a very cool idea for a project! > > > > > Someone from the mobileread forum already implemented a open source java > > > replacement for the environment [1]. He used the native einkfb library > > > [2] to write into the eink framebuffer. > > > > Ok, looks like fbdev with some extended ioctls. > > > > > I would like to have a "normal" compositor and shell to be able to run > > > gtk or qt applications on the eink device. I already looked over the > > > weston code and I think that all I have to do is to make a fork of > > > framebuffer compositor where I add eink support and to implement a > > > tablet shell for this device class. > > > > Yes, starting from compositor-fbdev.c is the way to go. > > > > Note, that if you go with tablet-shell, then all toolkits need to > > specifically have support for it. An initially easier route would be to > > bend the desktop-shell to work on the device, though I guess it might > > not be a good match for the user interface paradigm. So I suggest > > starting with desktop-shell, and seeing what you need to break to make > > the UI nice and usable. > > > > > I don't have experience in this field (eink and compositors), but here > > > are some issues I am currently thinking of: > > > 1. eink display should only repaint if something changed and only with a > > > limited fps (if someone get the crazy idea to watch videos with it) > > > 2. repainting should only happen to the area/pixels that changed and > > > every x times repainting the whole display. > > > > Weston already has infrastructure in place to both repaint only the > > damage, and to throttle the framerate all the way down to clients. In > > your backend, you can force a full repaint as needed, I think. You may > > want to look into the pixman renderer and fbdev backend for more > > details. > > > > I looked at the einkfb code, and it seems the wait for screen update to > > complete is blocking. That is not too good, since it would block the > > whole compositor. You may need to put that ioctl into a separate > > thread to have it run async, and then signal the completion. For an > > example of how to handle a completion function call from a different > > thread, see the flippipe code in compositor-rpi.c. > > > > If you can get an event via the device file descriptor, making the fd > > readable when the screen update has completed, that would integrate > > well with the main loop in weston. If not, you need the flippipe > > relay. > > > > > 3. There are many different eink devices with out there. Is there a > > > possibility to write an abstraction layer? > > > > Don't write an abstraction layer as the first thing. When we get the > > third different eink driver for weston, then it becomes possible to > > see if an abstraction could be designed, or if they only want some > > helpers for the common code. > > > > Ideally, there would be DRM/KMS drivers for all eink displays, so a > > user space abstraction would not be needed. How feasible that is, I do > > not know, and I think it would also be out of scope for your thesis. > > > > (DRM/KMS drivers do not *have to* support acceleration, I believe they > > could be written to support only dumb buffers, which are generic.) > > > > > When rendering works I would start working on a tablet shell. > > > > > > Do you have some constructive comments/ideas? > > > > Is the input exposed as standard evdev input devices? Is there udev? > > > > > Do you think this idea is realizable within a master thesis for a > > > beginner like me? > > > > I
Re: Compositor for eink device
Am Dienstag, den 11.06.2013, 12:38 +0300 schrieb Pekka Paalanen: > On Tue, 11 Jun 2013 08:44:15 +0200 > Claudius Marpa Heine > wrote: > > Hi Claudius, > > that is a very cool idea for a project! Thank, I like to hear that ;) > > Someone from the mobileread forum already implemented a open source java > > replacement for the environment [1]. He used the native einkfb library > > [2] to write into the eink framebuffer. > > Ok, looks like fbdev with some extended ioctls. > > > I would like to have a "normal" compositor and shell to be able to run > > gtk or qt applications on the eink device. I already looked over the > > weston code and I think that all I have to do is to make a fork of > > framebuffer compositor where I add eink support and to implement a > > tablet shell for this device class. > > Yes, starting from compositor-fbdev.c is the way to go. > > Note, that if you go with tablet-shell, then all toolkits need to > specifically have support for it. Do you mean that qt, gtk, efl, etc. which already have support for wayland don't work with the tablet-shell and there is no way of compiling it with support? And the desktop-shell don't support touch input and has to be broken apart to build a more tablet style UI. That's misfortune. How difficult could it be to add touch input into the desktop-shell? Under this circumstances maybe I should take a deeper lock into qt-wayland. > > When rendering works I would start working on a tablet shell. > > > > Do you have some constructive comments/ideas? > > Is the input exposed as standard evdev input devices? Is there udev? Yes it's a standard evdev device and udev is available. So input, I thought until now, would not be a problem. > We have been craving for a good example of a completely different > shell than the desktop oriented ones, to make a point of what shells > actually are supposed to be. If you could make that point, that would > be brilliant! I'm happy to be of service ;) (If I find a professor willing to supervise my thesis) Claudius signature.asc Description: This is a digitally signed message part ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor for eink device
Am Dienstag, den 11.06.2013, 13:16 +0300 schrieb Pekka Paalanen: > On Tue, 11 Jun 2013 10:56:49 +0100 > martin brook wrote: > > > Guys Hi, > > > > An interesting area which I've done some work on with a kobo touch, some > > useful links at > > > > https://wiki.merproject.org/wiki/Community_Workspace/kobo > > Ok, only static pseudocolor, of course. Hopefully that matches PIXMAN_g8 > format and pixman does the conversion automatically and without too > much hit. > > The current pixman renderer in Weston is written for ARGB > compositing of client provided images. It is wasteful to first > composite in ARGB and then convert to grayscale, so if that needs > optimizing, you may need to: > - convert incoming buffers to grayscale and maintain a copy > - modify the pixman renderer to composite in grayscale+alpha, if > possible > - add a grayscale pixel format to wl_shm protocol (I have planned on > adding more formats anyway) > - modifying clients to use the grayscale format > > But I think it is possible to start with the pixman renderer as is, and > convert to grayscale when copying to the fb. Not sure if that helps, but someone successfully converted the content of the framebuffer to RGB: http://www.chauveau-central.net/pub/KoboTouch/ Regards Claudius signature.asc Description: This is a digitally signed message part ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH]: mtdev could be disabled at configuration
On Tue, 11 Jun 2013 12:10:05 +0200 Benjamin Tissoires wrote: > On Tue, Jun 11, 2013 at 9:41 AM, Pekka Paalanen wrote: > > On Tue, 11 Jun 2013 09:01:48 +0200 > > Benjamin Tissoires wrote: > > > >> On Mon, Jun 10, 2013 at 8:42 AM, Pekka Paalanen > >> wrote: > >> > On Fri, 7 Jun 2013 12:11:14 +0200 > >> > Marc Chalain wrote: > >> > > >> >> mtdev is not necessary on some device (desktop or set-top-box). For > >> >> embedded solution the minimum of dependencies is required. "configure" > >> >> accepts the --disable-mtdev option. > >> > > >> > Hi Marc, > >> > > >> > with this patch, if weston is compiled with --disable-mtdev, it looks > >> > like it will still happily open multitouch devices, expose them to > >> > Wayland clients, and feed them garbage or fail or whatever. Right? > >> > >> Hi Pekka, > >> > >> no. mtdev is a compatibility layer for converting very rare > >> touchscreen using the multitouch protocol A into the mostly used > >> multitouch protocol B. > >> To my mind, only legacy devices (ntrig 0001 and few others) use the > >> protocol A. > >> So without mtdev, wayland will open and handle most of the multitouch > >> screen happily. > >> > >> > > >> > I think the proper approach is to change the configure option into > >> > --disable-multitouch or --disable-touchscreen, which would not only > >> > drop the dependency to mtdev, but also make Weston ignore all > >> > touchscreen devices since it will not be able to handle them. > >> > >> Without mtdev, wayland should only ignore multitouch screen not > >> presenting the ABS_MT_SLOT axis. > >> Those relying on SYN_MT_REPORT do not provide tracking (which is done by > >> mtdev). > >> > >> So my guess is that if you detect multitouch screens by looking at > >> ABS_MT_SLOT, then everything will be fine whether or not you have > >> mtdev: > >> - multitouch B screens will correctly be handled > >> - multitouch A screens will be processed as a single touch screen, > >> which is not a problem because the kernel provides single touch > >> emulation since the early days of multitouch. And if mtdev is present, > >> then it will show the ABS_MT_SLOT axis, leading to the previous case. > >> > >> Bonus point, mtdev has not been updated since a long time, and is > >> missing the bits allowing you to retrieve the initial per-slot states. > >> And you may find useful to retrieve the current states when weston > >> launches. > > > > Thank you for clarifying that, Benjamin. > > > > Does this mean that we need explicit single-touch support in Weston? > > After giving a quick look at evdev.c, it appears that single touch > devices are already treated in the same way tablets (with stylus) are. > So, single touch devices are seen from weston in the same way they > have been seen in Xorg since the beginning: as absolute input devices. > > Then, it's just a matter of deciding whether we want to inform the > client if the source of the event is a finger or a pen. Right... except we do not support tablets at all at the moment. We miss the whole protocol for tablets. Wayland (not just Weston) only has support for touchscreens so far, in addition to keyboards and relative pointing devices. evdev.c's device type recognition is just a handful of ad hoc heuristics for now, written only for touschscreens, keyboards, and mice/touchpads, and trying to ignore everything else. > > I don't think we have that yet. Everything touchy goes through mtdev, > > which makes also real single-touch devices look like multitouch devices > > except they never report more than one contact. Do I understand that > > right? > > evdev.c detects "touch" devices by looking at ABS_MT_SLOT. But mtdev > does not transform single touch device into pseudo-multitouch devices. > So I would say that those single touch devices are not treated as > "touch" today. Ok, so probably they would not work anyway atm. Which means that dropping mtdev loses only some rare multitouch devices, which do not advertise ABS_MT_SLOT, and hence will get properly ignored. Right? I wonder if single-touch devices get detected as touchpads. Depends on if they have any keys, it seems. :-) > > Marc, in any case, I think you should check that Weston correctly > > ignores touch devices it cannot support without mtdev, as per > > Benjamin's instructions above. > > > > Retrieving current state is a matter for another time. > > > > Oh yes. FYI, I still did not found the time to finalize the patches for Xorg > :) Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor for eink device
On Tue, 11 Jun 2013 12:37:33 +0200 Claudius Marpa Heine wrote: > Am Dienstag, den 11.06.2013, 13:16 +0300 schrieb Pekka Paalanen: > > On Tue, 11 Jun 2013 10:56:49 +0100 > > martin brook wrote: > > > > > Guys Hi, > > > > > > An interesting area which I've done some work on with a kobo touch, some > > > useful links at > > > > > > https://wiki.merproject.org/wiki/Community_Workspace/kobo > > > > Ok, only static pseudocolor, of course. Hopefully that matches PIXMAN_g8 > > format and pixman does the conversion automatically and without too > > much hit. > > > > The current pixman renderer in Weston is written for ARGB > > compositing of client provided images. It is wasteful to first > > composite in ARGB and then convert to grayscale, so if that needs > > optimizing, you may need to: > > - convert incoming buffers to grayscale and maintain a copy > > - modify the pixman renderer to composite in grayscale+alpha, if > > possible > > - add a grayscale pixel format to wl_shm protocol (I have planned on > > adding more formats anyway) > > - modifying clients to use the grayscale format > > > > But I think it is possible to start with the pixman renderer as is, and > > convert to grayscale when copying to the fb. > > Not sure if that helps, but someone successfully converted the content > of the framebuffer to RGB: > http://www.chauveau-central.net/pub/KoboTouch/ That seems to be a different color format than in the Mer wiki link. The same caveats may still apply. In any case, you have the chance to convert to the right format when copying from the shadow to the real fb. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor for eink device
On Tue, 11 Jun 2013 12:28:21 +0200 Claudius Marpa Heine wrote: > Am Dienstag, den 11.06.2013, 12:38 +0300 schrieb Pekka Paalanen: > > On Tue, 11 Jun 2013 08:44:15 +0200 > > Claudius Marpa Heine > > wrote: > > > > Hi Claudius, > > > > that is a very cool idea for a project! > > Thank, I like to hear that ;) > > > > Someone from the mobileread forum already implemented a open source java > > > replacement for the environment [1]. He used the native einkfb library > > > [2] to write into the eink framebuffer. > > > > Ok, looks like fbdev with some extended ioctls. > > > > > I would like to have a "normal" compositor and shell to be able to run > > > gtk or qt applications on the eink device. I already looked over the > > > weston code and I think that all I have to do is to make a fork of > > > framebuffer compositor where I add eink support and to implement a > > > tablet shell for this device class. > > > > Yes, starting from compositor-fbdev.c is the way to go. > > > > Note, that if you go with tablet-shell, then all toolkits need to > > specifically have support for it. > > Do you mean that qt, gtk, efl, etc. which already have support for > wayland don't work with the tablet-shell and there is no way of > compiling it with support? > And the desktop-shell don't support touch input and has to be broken > apart to build a more tablet style UI. > That's misfortune. There are different things at play here. Both shells consist of several parts: public Wayland protocol interfaces towards clients, a Weston plugin, and a helper client (e.g. weston-desktop-shell). See also http://cgit.freedesktop.org/wayland/weston/tree/notes.txt Tablet-shell uses different protocol towards Wayland clients than desktop-shell. Clients (usually toolkits) need to be explicitly written to support the shell protocol. This means that tablet-shell has poor chances of running any desktop applications. Desktop-shell is what almost everyone writes the toolkit support for, so that is not a problem. The problem with desktop-shell is that you need to enhance weston-desktop-shell to use touch input. > How difficult could it be to add touch input into the desktop-shell? Not too difficult. You just need to decide how the desktop should respond to touches, and implement that in weston-desktop-shell. You can do that in isolation, no need to modify toolkits, protocol, weston, or weston plugins. Well, you may need to modify the toytoolkit coming with weston, since weston-desktop-shell uses it, to add support for touch input. But I guess if you only need the launcher panel buttons to react to touch, you could just hack it in clients/desktop-shell.c of weston repository. Oh, and nothing prevents you from writing a total replacement for weston-desktop-shell, or forking the desktop shell plugin. So even if you will be using desktop shell protocol wise, you can still have your own "desktop". > Under this circumstances maybe I should take a deeper lock into > qt-wayland. > > > > When rendering works I would start working on a tablet shell. > > > > > > Do you have some constructive comments/ideas? > > > > Is the input exposed as standard evdev input devices? Is there udev? > > Yes it's a standard evdev device and udev is available. So input, I > thought until now, would not be a problem. Sounds ok, if the touchscreen advertises ABS_MT_SLOT. If it does not, you get to do some input plumbing in weston, too. And looking at http://www.chauveau-central.net/pub/KoboTouch/ , there is no ABS_MT_SLOT. So, maybe a week of work to get that hooked up and upstreamed. HTH, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 1/3] gl-renderer: Track the buffer type in gl_surface_state
On Fri, 7 Jun 2013 16:52:44 +0300 Ander Conselvan de Oliveira wrote: > Checking for gs->num_images for determining the previous buffer type > when attaching is not reliable. The number of images is never cleared > in the SHM path, so after a switch from an EGL buffer to SHM, every > following attach of an SHM buffer will happen with gs->num_images > 0, > and the code will assume the previous buffer was an EGL one. > > Fix this by adding a buffer_type field to gl_surface_state. > --- > src/gl-renderer.c | 21 + > 1 file changed, 17 insertions(+), 4 deletions(-) I like tracking buffer type explicitly, rather than inferring from num_images. This series looks ok and seems to work ok from what little testing I did. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/4] input: Add a weston_pointer_output_center
On Mon, 10 Jun 2013 15:17:29 +0100
Rob Bradford wrote:
> From: Rob Bradford
>
> Centre the pointer on a the provided output. This function provides the
> basis of ensuring that the pointer starts on the output when we start to
> constrain a seat to a given output.
> ---
> src/compositor.h | 3 +++
> src/input.c | 8
> 2 files changed, 11 insertions(+)
>
> diff --git a/src/compositor.h b/src/compositor.h
> index 22700b7..d2ca844 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -333,6 +333,9 @@ weston_pointer_start_grab(struct weston_pointer *pointer,
> struct weston_pointer_grab *grab);
> void
> weston_pointer_end_grab(struct weston_pointer *pointer);
> +void
> +weston_pointer_output_center(struct weston_pointer *pointer,
> + struct weston_output *output);
>
> struct weston_keyboard *
> weston_keyboard_create(void);
> diff --git a/src/input.c b/src/input.c
> index d299d98..7c7aa95 100644
> --- a/src/input.c
> +++ b/src/input.c
> @@ -473,6 +473,14 @@ weston_pointer_set_focus(struct weston_pointer *pointer,
> }
>
> WL_EXPORT void
> +weston_pointer_output_center(struct weston_pointer *pointer,
> + struct weston_output *output)
> +{
> + pointer->x = wl_fixed_from_int(output->x + output->width / 2);
> + pointer->y = wl_fixed_from_int(output->y + output->height / 2);
What about all the processing that happens in input.c notify_motion()
and move_pointer(), is that really not needed here?
> +}
> +
> +WL_EXPORT void
> weston_keyboard_set_focus(struct weston_keyboard *keyboard,
> struct weston_surface *surface)
> {
More questions on the next patch,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] cursor in editor.c now goes to a newline
--- clients/editor.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/clients/editor.c b/clients/editor.c index bfb6fe1..3786e40 100644 --- a/clients/editor.c +++ b/clients/editor.c @@ -946,8 +946,8 @@ text_entry_draw_cursor(struct text_entry *entry, cairo_t *cr) &cursor_pos, NULL); cairo_set_line_width(cr, 1.0); - cairo_move_to(cr, PANGO_PIXELS(cursor_pos.x), PANGO_PIXELS(extents.height) + 2); - cairo_line_to(cr, PANGO_PIXELS(cursor_pos.x), - 2); + cairo_move_to(cr, PANGO_PIXELS(cursor_pos.x), PANGO_PIXELS(cursor_pos.y)); + cairo_line_to(cr, PANGO_PIXELS(cursor_pos.x), PANGO_PIXELS(cursor_pos.y) + PANGO_PIXELS(cursor_pos.height)); cairo_stroke(cr); } -- 1.8.3.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 3/4] compositor-drm: Enable seat constraining when configured in weston.ini
Hi Rob,
I think patches 2, 3, and 4 should be all squashed, and I would like to
know more of what is the use case here.
More questions below.
On Mon, 10 Jun 2013 15:17:30 +0100
Rob Bradford wrote:
> From: Rob Bradford
>
> ---
> src/compositor-drm.c | 16
> src/compositor.h | 2 ++
> src/input.c | 2 ++
> src/udev-seat.c | 3 +++
> 4 files changed, 23 insertions(+)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 76d0810..7d33977 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -1796,6 +1796,22 @@ create_output_for_connector(struct drm_compositor *ec,
> transform = parse_transform(s, output->base.name);
> free(s);
>
> + weston_config_section_get_string(section, "seat", &s, "");
> + if (strcmp(s, "") != 0) {
> + struct udev_seat *seat;
> +
> + seat = udev_seat_get_named(&ec->base, s);
> + if (seat) {
> + seat->base.output = &output->base;
> + if (seat->base.pointer) {
> + weston_pointer_output_center(seat->base.pointer,
> + &output->base);
Does this mean, that every time an output is hotplugged in this seat,
the pointer will warp?
What if a seat has several outputs?
> + }
> + }
> + }
> +
> + free(s);
> +
> output->crtc_id = resources->crtcs[i];
> output->pipe = i;
> ec->crtc_allocator |= (1 << output->crtc_id);
> diff --git a/src/compositor.h b/src/compositor.h
> index d2ca844..68845ab 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -425,6 +425,8 @@ struct weston_seat {
> struct weston_keyboard *keyboard;
> struct weston_touch *touch;
>
> + struct weston_output *output; /* constraint */
> +
> struct wl_signal destroy_signal;
>
> struct weston_compositor *compositor;
> diff --git a/src/input.c b/src/input.c
> index 7c7aa95..ef99899 100644
> --- a/src/input.c
> +++ b/src/input.c
> @@ -585,6 +585,8 @@ clip_pointer_motion(struct weston_seat *seat, wl_fixed_t
> *fx, wl_fixed_t *fy)
> old_y = wl_fixed_to_int(seat->pointer->y);
>
> wl_list_for_each(output, &ec->output_list, link) {
> + if (seat->output && seat->output != output)
> + continue;
> if (pixman_region32_contains_point(&output->region,
> x, y, NULL))
> valid = 1;
> diff --git a/src/udev-seat.c b/src/udev-seat.c
> index bd25535..8df588a 100644
> --- a/src/udev-seat.c
> +++ b/src/udev-seat.c
> @@ -115,6 +115,9 @@ device_added(struct udev_device *udev_device, struct
> udev_input *input)
>
> wl_list_insert(seat->devices_list.prev, &device->link);
>
> + if (seat->base.output && seat->base.pointer)
> + weston_pointer_output_center(seat->base.pointer,
> seat->base.output);
Do I understand right, that whenever any input device is hotplugged,
like a keyboard, the pointer will warp?
> +
> return 0;
> }
>
>From the man page patch:
+.BI "seat=" name
+The logical seat name that that this output should be associated with. If this
+is set then the seat's input will be confined to the output that has the seat
+set on it. The expectation is that this functionality will be used in a
+multiheaded environment with a single compositor for multiple output and
+input configurations.
So, this is an output key. It is almost as if you were trying to
implement seats by using wl_seats. I don't think that will work. Like
here, you try to confine the pointer, but what if a user alt+tabs? No
constraints there. I'm confused what this is trying to achieve.
Let me explain. I believe that wl_seat is misnamed. wl_seat is a set of
foci for a set on input devices, used by one person, or by several
people collaborating on a common desktop. Everyone has access to
everything, using their own input devices.
A seat is a physical entity, a console; an output or outputs, and the
associated input devices. Each seat has its own user session(s), which
is easiest to implement by running a compositor per seat. Sessions are
separate by definition, and for security. Separating the sessions within
a compositor is very hard.
I think, that seats are configured in udev, and wl_seats will be
configured in weston.ini or equivalent per-session configuration. A seat
may have multiple wl_seats, if you want e.g. multi-pointer. Currently,
we have no implementation for configuring multiple wl_seats;
device_added() will ignore all devices that do not match the wanted
ID_SEAT property, and only one udev_input with a wanted seat_id is
created in a backend.
Could you elaborate on what you are trying to do?
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wa
Re: [fbdev_backend] initialization of the first frame buffer
[PATCH] [compositor-fbdev]: set the yoffset value to 0
The memory buffer could be twice larger than the screen size to use
double buffering.
The application writes alternatively inside each middle of the memory.
The 'yoffset' field of varinfo, is used to switch from a memory part to
the other.
The value is not always initialized to 0.
---
src/compositor-fbdev.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 9c3d17e..91d0623 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -330,6 +330,11 @@ fbdev_query_screen_info(struct fbdev_output *output,
int fd,
return -1;
}
+if (varinfo.yoffset != 0) {
+varinfo.yoffset= 0;
+if (ioctl(fd, FBIOPAN_DISPLAY, &varinfo) < 0)
+return -1;
+}
return 1;
}
@@ -366,6 +371,7 @@ fbdev_set_screen_info(struct fbdev_output *output, int
fd,
varinfo.blue.length = 8;
varinfo.blue.msb_right = 0;
+varinfo.yoffset = 0;
/* Set the device's screen information. */
if (ioctl(fd, FBIOPUT_VSCREENINFO, &varinfo) < 0) {
return -1;
--
1.7.9.5
2013/6/10 Marc Chalain
> Ok I will try to write a better commit message.
> But for frame buffer understanding, the buffer is often allowed for a
> screen with the double of height as showed. Then is possible to set the
> buffer with two screens, one above the other. After we switch the display
> from the first middle buffer to the next one with "yoffset" and the
> FIBIOPAN_DISPLAY. Normally it's used to have double buffering and improve
> the number of frames per second (double buffering).
> But the problem is that yoffset is not always configured to 0 at the
> startup and we have to set it.
>
> I plan to add double buffering but in few days.
> Marc.
>
> PS: I have to support SurfaceFlinger (Android) as wayland client. It's the
> reason of my work. But I can stay a long time on my weston patches...
>
>
>
> 2013/6/10 Pekka Paalanen
>
>> On Fri, 7 Jun 2013 17:20:23 +0200
>> Marc Chalain wrote:
>>
>> > From 6553ed3ad9845113f3b2280e6fc94e2b326a7eca Mon Sep 17 00:00:00 2001
>> > From: mchalain
>> > Date: Fri, 7 Jun 2013 17:18:23 +0200
>> > Subject: [PATCH 2/2] [fbdev_backend] initialization of the first frame
>> > buffer
>> >
>> > ---
>> > src/compositor-fbdev.c |8 +++-
>> > 1 file changed, 7 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
>> > index d6d911a..e6c761f 100644
>> > --- a/src/compositor-fbdev.c
>> > +++ b/src/compositor-fbdev.c
>> > @@ -277,7 +277,7 @@ calculate_pixman_format(struct fb_var_screeninfo
>> *vinfo,
>> > if (finfo->visual == FB_VISUAL_DIRECTCOLOR)
>> > build_cmap(vinfo, cmap);
>> > else
>> > - /* We only handle true-colour frame buffers at the moment. */
>> > +/* We only handle true-colour frame buffers at the moment. */
>> > if (finfo->visual != FB_VISUAL_TRUECOLOR || vinfo->grayscale != 0)
>> > return 0;
>> >
>> > @@ -373,6 +373,11 @@ fbdev_query_screen_info(struct fbdev_output
>> *output,
>> > int fd,
>> > return -1;
>> > }
>> >
>> > +if (varinfo.yoffset != 0) {
>> > +varinfo.yoffset= 0;
>> > +if (ioctl(fd, FBIOPAN_DISPLAY, &varinfo) < 0)
>> > +return -1;
>> > +}
>> > return 1;
>> > }
>> >
>> > @@ -409,6 +414,7 @@ fbdev_set_screen_info(struct fbdev_output *output,
>> int
>> > fd,
>> > varinfo.blue.length = 8;
>> > varinfo.blue.msb_right = 0;
>> >
>> > +varinfo.yoffset = 0;
>> > /* Set the device's screen information. */
>> > if (ioctl(fd, FBIOPUT_VSCREENINFO, &varinfo) < 0) {
>> > return -1;
>>
>> Hi Marc,
>>
>> I admit I am not familiar with the fbdev interface, but this patch is
>> missing a commit message. I have no clue what is going on here, and I
>> could not understand the note for this patch in the previous email.
>>
>> If you don't know what to write in a commit message, the following two
>> links give a good idea:
>>
>> https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages
>> http://who-t.blogspot.de/2009/12/on-commit-messages.html
>>
>> The same comment about a missing commit message applies to your
>> latest "DIRECTCOLOR" patch, too.
>>
>>
>> Thanks,
>> pq
>>
>
>
0001-compositor-fbdev-set-the-yoffset-value-to-0.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH]: mtdev could be disabled at configuration
On Tue, Jun 11, 2013 at 12:40 PM, Pekka Paalanen wrote: > On Tue, 11 Jun 2013 12:10:05 +0200 > Benjamin Tissoires wrote: > >> On Tue, Jun 11, 2013 at 9:41 AM, Pekka Paalanen wrote: >> > On Tue, 11 Jun 2013 09:01:48 +0200 >> > Benjamin Tissoires wrote: >> > >> >> On Mon, Jun 10, 2013 at 8:42 AM, Pekka Paalanen >> >> wrote: >> >> > On Fri, 7 Jun 2013 12:11:14 +0200 >> >> > Marc Chalain wrote: >> >> > >> >> >> mtdev is not necessary on some device (desktop or set-top-box). For >> >> >> embedded solution the minimum of dependencies is required. "configure" >> >> >> accepts the --disable-mtdev option. >> >> > >> >> > Hi Marc, >> >> > >> >> > with this patch, if weston is compiled with --disable-mtdev, it looks >> >> > like it will still happily open multitouch devices, expose them to >> >> > Wayland clients, and feed them garbage or fail or whatever. Right? >> >> >> >> Hi Pekka, >> >> >> >> no. mtdev is a compatibility layer for converting very rare >> >> touchscreen using the multitouch protocol A into the mostly used >> >> multitouch protocol B. >> >> To my mind, only legacy devices (ntrig 0001 and few others) use the >> >> protocol A. >> >> So without mtdev, wayland will open and handle most of the multitouch >> >> screen happily. >> >> >> >> > >> >> > I think the proper approach is to change the configure option into >> >> > --disable-multitouch or --disable-touchscreen, which would not only >> >> > drop the dependency to mtdev, but also make Weston ignore all >> >> > touchscreen devices since it will not be able to handle them. >> >> >> >> Without mtdev, wayland should only ignore multitouch screen not >> >> presenting the ABS_MT_SLOT axis. >> >> Those relying on SYN_MT_REPORT do not provide tracking (which is done by >> >> mtdev). >> >> >> >> So my guess is that if you detect multitouch screens by looking at >> >> ABS_MT_SLOT, then everything will be fine whether or not you have >> >> mtdev: >> >> - multitouch B screens will correctly be handled >> >> - multitouch A screens will be processed as a single touch screen, >> >> which is not a problem because the kernel provides single touch >> >> emulation since the early days of multitouch. And if mtdev is present, >> >> then it will show the ABS_MT_SLOT axis, leading to the previous case. >> >> >> >> Bonus point, mtdev has not been updated since a long time, and is >> >> missing the bits allowing you to retrieve the initial per-slot states. >> >> And you may find useful to retrieve the current states when weston >> >> launches. >> > >> > Thank you for clarifying that, Benjamin. >> > >> > Does this mean that we need explicit single-touch support in Weston? >> >> After giving a quick look at evdev.c, it appears that single touch >> devices are already treated in the same way tablets (with stylus) are. >> So, single touch devices are seen from weston in the same way they >> have been seen in Xorg since the beginning: as absolute input devices. >> >> Then, it's just a matter of deciding whether we want to inform the >> client if the source of the event is a finger or a pen. > > Right... except we do not support tablets at all at the moment. We miss > the whole protocol for tablets. Wayland (not just Weston) only has > support for touchscreens so far, in addition to keyboards and relative > pointing devices. > > evdev.c's device type recognition is just a handful of ad hoc > heuristics for now, written only for touschscreens, keyboards, and > mice/touchpads, and trying to ignore everything else. Right, the current recognition seems to be even worth than what udev does (in the sense that it is not a complete characterization, no offense). I followed the thread from David Herrman about libinputmapper and hopefully, we will get in the end a more robust detection of input devices. > >> > I don't think we have that yet. Everything touchy goes through mtdev, >> > which makes also real single-touch devices look like multitouch devices >> > except they never report more than one contact. Do I understand that >> > right? >> >> evdev.c detects "touch" devices by looking at ABS_MT_SLOT. But mtdev >> does not transform single touch device into pseudo-multitouch devices. >> So I would say that those single touch devices are not treated as >> "touch" today. > > Ok, so probably they would not work anyway atm. > > Which means that dropping mtdev loses only some rare multitouch > devices, which do not advertise ABS_MT_SLOT, and hence will get > properly ignored. Right? right :) > > I wonder if single-touch devices get detected as touchpads. Depends on > if they have any keys, it seems. :-) They should not: the udev mapping for touchpads rely on BTN_TOOL_FINGER, so normally, the kernel will not set this property for single touch screen (we try to not break existing in the kernel, and the existing detection mechanism rely on BTN_TOOL_FINGER...). But again, this is the theory :) Cheers, Benjamin > >> > Marc, in any case, I think you should check that Weston correctly
Re: [PATCH]: mtdev could be disabled at configuration
Hello The detection of the library is automatically done during the configuration. The option is not useful. And the use #ifdef HAVE_MTDEV seems to be simpler, if in the future this feature will disappear. What I do ? I send again or I increase the complexity. Marc. 2013/6/11 Benjamin Tissoires > On Tue, Jun 11, 2013 at 12:40 PM, Pekka Paalanen > wrote: > > On Tue, 11 Jun 2013 12:10:05 +0200 > > Benjamin Tissoires wrote: > > > >> On Tue, Jun 11, 2013 at 9:41 AM, Pekka Paalanen > wrote: > >> > On Tue, 11 Jun 2013 09:01:48 +0200 > >> > Benjamin Tissoires wrote: > >> > > >> >> On Mon, Jun 10, 2013 at 8:42 AM, Pekka Paalanen > wrote: > >> >> > On Fri, 7 Jun 2013 12:11:14 +0200 > >> >> > Marc Chalain wrote: > >> >> > > >> >> >> mtdev is not necessary on some device (desktop or set-top-box). > For > >> >> >> embedded solution the minimum of dependencies is required. > "configure" > >> >> >> accepts the --disable-mtdev option. > >> >> > > >> >> > Hi Marc, > >> >> > > >> >> > with this patch, if weston is compiled with --disable-mtdev, it > looks > >> >> > like it will still happily open multitouch devices, expose them to > >> >> > Wayland clients, and feed them garbage or fail or whatever. Right? > >> >> > >> >> Hi Pekka, > >> >> > >> >> no. mtdev is a compatibility layer for converting very rare > >> >> touchscreen using the multitouch protocol A into the mostly used > >> >> multitouch protocol B. > >> >> To my mind, only legacy devices (ntrig 0001 and few others) use the > protocol A. > >> >> So without mtdev, wayland will open and handle most of the multitouch > >> >> screen happily. > >> >> > >> >> > > >> >> > I think the proper approach is to change the configure option into > >> >> > --disable-multitouch or --disable-touchscreen, which would not only > >> >> > drop the dependency to mtdev, but also make Weston ignore all > >> >> > touchscreen devices since it will not be able to handle them. > >> >> > >> >> Without mtdev, wayland should only ignore multitouch screen not > >> >> presenting the ABS_MT_SLOT axis. > >> >> Those relying on SYN_MT_REPORT do not provide tracking (which is > done by mtdev). > >> >> > >> >> So my guess is that if you detect multitouch screens by looking at > >> >> ABS_MT_SLOT, then everything will be fine whether or not you have > >> >> mtdev: > >> >> - multitouch B screens will correctly be handled > >> >> - multitouch A screens will be processed as a single touch screen, > >> >> which is not a problem because the kernel provides single touch > >> >> emulation since the early days of multitouch. And if mtdev is > present, > >> >> then it will show the ABS_MT_SLOT axis, leading to the previous case. > >> >> > >> >> Bonus point, mtdev has not been updated since a long time, and is > >> >> missing the bits allowing you to retrieve the initial per-slot > states. > >> >> And you may find useful to retrieve the current states when weston > >> >> launches. > >> > > >> > Thank you for clarifying that, Benjamin. > >> > > >> > Does this mean that we need explicit single-touch support in Weston? > >> > >> After giving a quick look at evdev.c, it appears that single touch > >> devices are already treated in the same way tablets (with stylus) are. > >> So, single touch devices are seen from weston in the same way they > >> have been seen in Xorg since the beginning: as absolute input devices. > >> > >> Then, it's just a matter of deciding whether we want to inform the > >> client if the source of the event is a finger or a pen. > > > > Right... except we do not support tablets at all at the moment. We miss > > the whole protocol for tablets. Wayland (not just Weston) only has > > support for touchscreens so far, in addition to keyboards and relative > > pointing devices. > > > > evdev.c's device type recognition is just a handful of ad hoc > > heuristics for now, written only for touschscreens, keyboards, and > > mice/touchpads, and trying to ignore everything else. > > Right, the current recognition seems to be even worth than what udev > does (in the sense that it is not a complete characterization, no > offense). > I followed the thread from David Herrman about libinputmapper and > hopefully, we will get in the end a more robust detection of input > devices. > > > > >> > I don't think we have that yet. Everything touchy goes through mtdev, > >> > which makes also real single-touch devices look like multitouch > devices > >> > except they never report more than one contact. Do I understand that > >> > right? > >> > >> evdev.c detects "touch" devices by looking at ABS_MT_SLOT. But mtdev > >> does not transform single touch device into pseudo-multitouch devices. > >> So I would say that those single touch devices are not treated as > >> "touch" today. > > > > Ok, so probably they would not work anyway atm. > > > > Which means that dropping mtdev loses only some rare multitouch > > devices, which do not advertise ABS_MT_SLOT, and hence will get > > properly ignored. Right? > > right
Re: [compositor] idle-time configuration inside weston.ini
You have right, it's the smallest of my patches, and the worst. [PATCH] [compositor]: add "idle-time" entry support in "core" section of weston.ini --- src/compositor.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/src/compositor.c b/src/compositor.c index 099600d..2002812 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -3277,6 +3277,8 @@ int main(int argc, char *argv[]) section = weston_config_get_section(config, "core", NULL, NULL); weston_config_section_get_string(section, "modules", &modules, "desktop-shell.so"); +weston_config_section_get_int(section, "idle-time", + &idle_time, idle_time); backend_init = load_module(backend, "backend_init"); if (!backend_init) -- 1.7.9.5 2013/6/10 Pekka Paalanen > On Fri, 7 Jun 2013 12:39:21 +0200 > Marc Chalain wrote: > > > this patch use the "idle-time" entry inside the "core" section of > > weston.ini to set the named value. > > Hi Marc, > > does this actually work? > > I think the backend init calls weston_compositor_init(), where your > code then loads the idle-time from config, and then later in main() > ec->idle_time is unconditionally set. To me it looks like the config > setting gets always overwritten. > > Also patch the man pages for this change, please. > > > Thanks, > pq > 0001-compositor-add-idle-time-entry-support-in-core-secti.patch Description: Binary data ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 3/4] compositor-drm: Enable seat constraining when configured in weston.ini
On 06/10/2013 05:17 PM, Rob Bradford wrote:
From: Rob Bradford
---
src/compositor-drm.c | 16
src/compositor.h | 2 ++
src/input.c | 2 ++
src/udev-seat.c | 3 +++
4 files changed, 23 insertions(+)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 76d0810..7d33977 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1796,6 +1796,22 @@ create_output_for_connector(struct drm_compositor *ec,
transform = parse_transform(s, output->base.name);
free(s);
+ weston_config_section_get_string(section, "seat", &s, "");
+ if (strcmp(s, "") != 0) {
+ struct udev_seat *seat;
+
+ seat = udev_seat_get_named(&ec->base, s);
+ if (seat) {
+ seat->base.output = &output->base;
+ if (seat->base.pointer) {
+ weston_pointer_output_center(seat->base.pointer,
+&output->base);
+ }
+ }
+ }
+
+ free(s);
+
I'd prefer if this was in a separate function. The function
create_output_for_connector() is too long as it is. And doing that you
could probably get rid of one indentation level, which would let you
rename weston_pointer_output_center() as
weston_pointer_center_on_output() (which is clearer IMO) without
breaking the 80 characters limit.
Cheers,
Ander
output->crtc_id = resources->crtcs[i];
output->pipe = i;
ec->crtc_allocator |= (1 << output->crtc_id);
diff --git a/src/compositor.h b/src/compositor.h
index d2ca844..68845ab 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -425,6 +425,8 @@ struct weston_seat {
struct weston_keyboard *keyboard;
struct weston_touch *touch;
+ struct weston_output *output; /* constraint */
+
struct wl_signal destroy_signal;
struct weston_compositor *compositor;
diff --git a/src/input.c b/src/input.c
index 7c7aa95..ef99899 100644
--- a/src/input.c
+++ b/src/input.c
@@ -585,6 +585,8 @@ clip_pointer_motion(struct weston_seat *seat, wl_fixed_t
*fx, wl_fixed_t *fy)
old_y = wl_fixed_to_int(seat->pointer->y);
wl_list_for_each(output, &ec->output_list, link) {
+ if (seat->output && seat->output != output)
+ continue;
if (pixman_region32_contains_point(&output->region,
x, y, NULL))
valid = 1;
diff --git a/src/udev-seat.c b/src/udev-seat.c
index bd25535..8df588a 100644
--- a/src/udev-seat.c
+++ b/src/udev-seat.c
@@ -115,6 +115,9 @@ device_added(struct udev_device *udev_device, struct
udev_input *input)
wl_list_insert(seat->devices_list.prev, &device->link);
+ if (seat->base.output && seat->base.pointer)
+ weston_pointer_output_center(seat->base.pointer,
seat->base.output);
+
return 0;
}
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH]: mtdev could be disabled at configuration
On Tue, 11 Jun 2013 14:41:18 +0200
Marc Chalain wrote:
> Hello
> The detection of the library is automatically done during the
> configuration. The option is not useful.
>
> And the use #ifdef HAVE_MTDEV seems to be simpler, if in the future this
> feature will disappear.
>
> What I do ? I send again or I increase the complexity.
Send again. I think distro packagers would like a ./configure switch
with yes/no/auto, defaulting to auto.
I didn't even realize the --disable-mtdev was not actually a configure
option.
Here's what I meant earlier (pseudo code):
#ifdef HAVE_MTDEV
#include
#else
struct mtdev
{
int dummy;
};
static inline int
mtdev_get(struct mtdev *, int, blah*, int)
{
return -1;
}
static inline void
mtdev_close_delete(struct mtdev *)
{
}
#endif
That way the significant code will have only one #ifdef after the above
in the top of the file.
device->mtdev will always be NULL, anyway, so these stubs will never be
called, and the compiler is still happy.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [fbdev_backend]: support of DIRECTCOLOR Frame buffer
Hello,
OK this patch now checks FB_VISUAL_DIRECTCOLOR twice but set the cmap
inside the fbdev_query_screen_info function.
I use "malloc" instead "table" declaration because it takes less memory and
it's used only once, it's useless to be faster.
After I set the same values for each colors, because it's a default map. To
set more finely we have to know the screen and it's capabilities.
I don't set the alpha when it's required (no alpha => no alpha map)
[PATCH] [compositor-fbdev]: DirectColor support
The backend accepts to use TRUECOLOR and DIRECTCOLOR which are similares.
DIRECTCOLOR has better results if the application applies a Colors map
before to use it.
The colors map is just a list of gradients for each colors and alpha.
---
src/compositor-fbdev.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 9c3d17e..c966d5a 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -203,6 +203,43 @@ finish_frame_handler(void *data)
return 1;
}
+static int
+set_cmap(int fd, struct fb_var_screeninfo *vinfo)
+{
+struct fb_cmap cmap;
+uint16_t *colors;
+int i;
+int rcols = 1 << vinfo->red.length;
+int gcols = 1 << vinfo->green.length;
+int bcols = 1 << vinfo->blue.length;
+
+memset(&cmap, 0, sizeof(cmap));
+
+/* Make our palette the length of the deepest color */
+int cols = (rcols > gcols ? rcols : gcols);
+cols = (cols > bcols ? cols : bcols);
+
+colors = malloc(sizeof(uint16_t) * cols);
+if (!colors) return -1;
+
+for (i = 0; i < rcols; i++)
+colors[i] = (UINT16_MAX / (rcols - 1)) * i;
+
+cmap.start = 0;
+cmap.len = cols;
+cmap.red = colors;
+cmap.blue = colors;
+cmap.green = colors;
+if (vinfo->transp.length)
+cmap.transp = colors;
+else
+cmap.transp = NULL;
+ioctl(fd, FBIOPUTCMAP, &cmap);
+
+free(colors);
+return 0;
+}
+
static pixman_format_code_t
calculate_pixman_format(struct fb_var_screeninfo *vinfo,
struct fb_fix_screeninfo *finfo)
@@ -242,7 +279,8 @@ calculate_pixman_format(struct fb_var_screeninfo *vinfo,
return 0;
/* We only handle true-colour frame buffers at the moment. */
-if (finfo->visual != FB_VISUAL_TRUECOLOR || vinfo->grayscale != 0)
+if (!(finfo->visual == FB_VISUAL_TRUECOLOR || finfo->visual ==
FB_VISUAL_DIRECTCOLOR)
+|| vinfo->grayscale != 0)
return 0;
/* We only support formats with MSBs on the left. */
@@ -325,6 +363,9 @@ fbdev_query_screen_info(struct fbdev_output *output,
int fd,
info->pixel_format = calculate_pixman_format(&varinfo, &fixinfo);
info->refresh_rate = calculate_refresh_rate(&varinfo);
+if (fixinfo.visual == FB_VISUAL_DIRECTCOLOR)
+set_cmap(fd, &varinfo);
+
if (info->pixel_format == 0) {
weston_log("Frame buffer uses an unsupported format.\n");
return -1;
--
1.7.9.5
2013/6/10 Pekka Paalanen
> On Fri, 7 Jun 2013 17:13:59 +0200
> Marc Chalain wrote:
>
> > From e30486e0288e7be526fc358a5318b344522e407b Mon Sep 17 00:00:00 2001
> > From: mchalain
> > Date: Fri, 7 Jun 2013 17:12:31 +0200
> > Subject: [PATCH] [fbdev_backend]: support of DIRECTCOLOR Frame buffer
> >
>
> A properly formatted title:
> compositor-fbdev: add direct color support
>
> Commit message is missing.
>
> > ---
> > src/compositor-fbdev.c | 49
> > +---
> > 1 file changed, 46 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> > index 9c3d17e..d6d911a 100644
> > --- a/src/compositor-fbdev.c
> > +++ b/src/compositor-fbdev.c
> > @@ -203,9 +203,42 @@ finish_frame_handler(void *data)
> > return 1;
> > }
> >
> > +static int
> > +build_cmap(struct fb_var_screeninfo *vinfo,
> > +struct fb_cmap *cmap)
> > +{
> > +uint16_t *colors;
> > +int i;
> > +int rcols = 1 << vinfo->red.length;
> > +int gcols = 1 << vinfo->green.length;
> > +int bcols = 1 << vinfo->blue.length;
> > +
> > +/* Make our palette the length of the deepest color */
> > +int cols = (rcols > gcols ? rcols : gcols);
> > +cols = (cols > bcols ? cols : bcols);
> > +
> > +colors = malloc(sizeof(uint16_t) * cols);
> > +if (!colors) return -1;
> > +
> > +for (i = 0; i < rcols; i++)
> > +colors[i] = (UINT16_MAX / (rcols - 1)) * i;
> > +
> > +cmap->start = 0;
> > +cmap->len = cols;
> > +cmap->red = colors;
> > +cmap->blue = colors;
> > +cmap->green = colors;
>
> If there actually is a difference between rcols, gcols, and bcols,
> should you not compute a different a 'colors' array for each different
> _cols?
>
> > +if (vinfo->transp.length)
> > +cmap->transp = colors;
> > +else
> > +cmap->transp = NULL;
>
> Now, 'colors' is malloc'd here. How does the caller of this
Re: [compositor] idle-time configuration inside weston.ini
On Tue, 11 Jun 2013 14:43:46 +0200 Marc Chalain wrote: > You have right, it's the smallest of my patches, and the worst. > > [PATCH] [compositor]: add "idle-time" entry support in "core" > section of weston.ini > > --- > src/compositor.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/compositor.c b/src/compositor.c > index 099600d..2002812 100644 > --- a/src/compositor.c > +++ b/src/compositor.c > @@ -3277,6 +3277,8 @@ int main(int argc, char *argv[]) > section = weston_config_get_section(config, "core", NULL, NULL); > weston_config_section_get_string(section, "modules", > &modules, "desktop-shell.so"); > +weston_config_section_get_int(section, "idle-time", > + &idle_time, idle_time); > > backend_init = load_module(backend, "backend_init"); > if (!backend_init) I think that should work. What about the man pages? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [fbdev_backend] initialization of the first frame buffer
On Tue, 11 Jun 2013 14:35:05 +0200
Marc Chalain wrote:
> [PATCH] [compositor-fbdev]: set the yoffset value to 0
> The memory buffer could be twice larger than the screen size to use
> double buffering.
> The application writes alternatively inside each middle of the memory.
> The 'yoffset' field of varinfo, is used to switch from a memory part to
> the other.
> The value is not always initialized to 0.
Ok, now it is at least explained.
Your commit title should be something like:
fbdev: ensure yoffset is zero
instead of "[fbdev_backend] initialization of the first frame buffer",
just FYI.
>
> ---
> src/compositor-fbdev.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> index 9c3d17e..91d0623 100644
> --- a/src/compositor-fbdev.c
> +++ b/src/compositor-fbdev.c
> @@ -330,6 +330,11 @@ fbdev_query_screen_info(struct fbdev_output *output,
> int fd,
> return -1;
> }
>
> +if (varinfo.yoffset != 0) {
> +varinfo.yoffset= 0;
> +if (ioctl(fd, FBIOPAN_DISPLAY, &varinfo) < 0)
> +return -1;
> +}
This is still a strange place to set it. A query function is not
expected to set, but I guess it will do since fbdev_set_screen_info()
is not called at startup I think.
> return 1;
> }
>
> @@ -366,6 +371,7 @@ fbdev_set_screen_info(struct fbdev_output *output, int
> fd,
> varinfo.blue.length = 8;
> varinfo.blue.msb_right = 0;
>
> +varinfo.yoffset = 0;
> /* Set the device's screen information. */
> if (ioctl(fd, FBIOPUT_VSCREENINFO, &varinfo) < 0) {
> return -1;
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] weston.pc: Added libexecdir and pkglibexecdir variables
On 06/11/2013 04:40 AM, sardemff7+wayl...@sardemff7.net wrote: > On 11/06/2013 08:05, Pekka Paalanen wrote: >> On Mon, 10 Jun 2013 14:40:19 -0300 >> "Eduardo Lima (Etrunko)" wrote: >>> >>> I have added the pkglibexedir in an attempt to avoid crowding libexecdir >>> too much. Other than that, no special reason. >>> >> >> Ok, so should the weston install paths be adjusted to pkglibexecdir? >> Could you write a patch for that? I think it might be a good idea. > > I can include it in a series to clean and move a few stuff around to > “more standard paths” if you want. Alright, please do it. :) Thank you, Eduardo -- Eduardo de Barros Lima (Etrunko) Software Engineer, Open Source Technology Center Intel Corporation São Paulo, Brazil eduardo.l...@linux.intel.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH]: mtdev could be disabled at configuration
OK I used macro instead inline function. It's the same for the compiler (in
this case).
evdev: add --disable-mtdev option to configure and bypass the mtdev
functions when the library is not available.
---
configure.ac | 17 ++---
src/evdev.c |9 -
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index b625221..2bdff35 100644
--- a/configure.ac
+++ b/configure.ac
@@ -132,7 +132,7 @@ AC_ARG_ENABLE(drm-compositor, [
--enable-drm-compositor],,
AM_CONDITIONAL(ENABLE_DRM_COMPOSITOR, test x$enable_drm_compositor = xyes
-a x$enable_egl = xyes)
if test x$enable_drm_compositor = xyes -a x$enable_egl = xyes; then
AC_DEFINE([BUILD_DRM_COMPOSITOR], [1], [Build the DRM compositor])
- PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm
mtdev >= 1.1.0])
+ PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm])
fi
@@ -161,7 +161,7 @@ AM_CONDITIONAL(ENABLE_RPI_COMPOSITOR, test
"x$enable_rpi_compositor" = "xyes")
have_bcm_host="no"
if test "x$enable_rpi_compositor" = "xyes"; then
AC_DEFINE([BUILD_RPI_COMPOSITOR], [1], [Build the compositor for
Raspberry Pi])
- PKG_CHECK_MODULES(RPI_COMPOSITOR, [libudev >= 136 mtdev >= 1.1.0])
+ PKG_CHECK_MODULES(RPI_COMPOSITOR, [libudev >= 136])
PKG_CHECK_MODULES(RPI_BCM_HOST, [bcm_host],
[have_bcm_host="yes"
AC_DEFINE([HAVE_BCM_HOST], [1], [have Raspberry Pi
BCM headers])],
@@ -176,7 +176,7 @@ AM_CONDITIONAL([ENABLE_FBDEV_COMPOSITOR],
[test x$enable_fbdev_compositor = xyes])
AS_IF([test x$enable_fbdev_compositor = xyes], [
AC_DEFINE([BUILD_FBDEV_COMPOSITOR], [1], [Build the fbdev compositor])
- PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev >= 136 mtdev >= 1.1.0])
+ PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev >= 136 ])
])
AC_ARG_ENABLE([rdp-compositor], [ --enable-rdp-compositor],,
@@ -203,6 +203,17 @@ PKG_CHECK_MODULES(WEBP, [libwebp], [have_webp=yes],
[have_webp=no])
AS_IF([test "x$have_webp" = "xyes"],
[AC_DEFINE([HAVE_WEBP], [1], [Have webp])])
+AC_ARG_ENABLE(mtdev,
+ AS_HELP_STRING([--disable-mtdev],
+ [do not support multitouch library
libmtdev]),,
+ enable_mtdev=auto)
+AM_CONDITIONAL(ENABLE_MTDEV, test "x$enable_mtdev" = "xyes")
+if test "x$enable_mtdev" != "xno"; then
+PKG_CHECK_MODULES(MTDEV, [mtdev >= 1.1.0], [have_mtdev=yes],
[have_mtdev=no])
+AS_IF([test "x$have_mtdev" = "xyes"],
+ [AC_DEFINE([HAVE_MTDEV], [1], [Have Multitouch device support])])
+fi
+
AC_CHECK_LIB([jpeg], [jpeg_CreateDecompress], have_jpeglib=yes)
if test x$have_jpeglib = xyes; then
JPEG_LIBS="-ljpeg"
diff --git a/src/evdev.c b/src/evdev.c
index 122a2d9..b2a5eba 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -27,7 +27,15 @@
#include
#include
#include
+#ifdef HAVE_MTDEV
#include
+#else
+struct mtdev
+{ int none;};
+#define mtdev_close_delete(...) do{}while(0)
+#define mtdev_get(...) 0
+#define mtdev_new_open(...) NULL
+#endif
#include "compositor.h"
#include "evdev.h"
@@ -565,7 +573,6 @@ evdev_device_create(struct weston_seat *seat, const
char *path, int device_fd)
if (device->dispatch == NULL)
goto err1;
-
if (device->is_mt) {
device->mtdev = mtdev_new_open(device->fd);
if (!device->mtdev)
--
1.7.9.5
2013/6/11 Pekka Paalanen
> On Tue, 11 Jun 2013 14:41:18 +0200
> Marc Chalain wrote:
>
> > Hello
> > The detection of the library is automatically done during the
> > configuration. The option is not useful.
> >
> > And the use #ifdef HAVE_MTDEV seems to be simpler, if in the future this
> > feature will disappear.
> >
> > What I do ? I send again or I increase the complexity.
>
> Send again. I think distro packagers would like a ./configure switch
> with yes/no/auto, defaulting to auto.
>
> I didn't even realize the --disable-mtdev was not actually a configure
> option.
>
> Here's what I meant earlier (pseudo code):
>
> #ifdef HAVE_MTDEV
> #include
> #else
> struct mtdev
> {
> int dummy;
> };
>
> static inline int
> mtdev_get(struct mtdev *, int, blah*, int)
> {
> return -1;
> }
>
> static inline void
> mtdev_close_delete(struct mtdev *)
> {
> }
> #endif
>
> That way the significant code will have only one #ifdef after the above
> in the top of the file.
>
> device->mtdev will always be NULL, anyway, so these stubs will never be
> called, and the compiler is still happy.
>
>
> Thanks,
> pq
>
0002-evdev-add-disable-mtdev-option-to-configure-and-bypa.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [fbdev_backend]: support of DIRECTCOLOR Frame buffer
On Tue, 11 Jun 2013 15:15:29 +0200
Marc Chalain wrote:
> Hello,
> OK this patch now checks FB_VISUAL_DIRECTCOLOR twice but set the cmap
> inside the fbdev_query_screen_info function.
> I use "malloc" instead "table" declaration because it takes less memory and
> it's used only once, it's useless to be faster.
> After I set the same values for each colors, because it's a default map. To
> set more finely we have to know the screen and it's capabilities.
What I meant is, if rcols = 32 and gcols = 64, you allocate a 64-long
array, and fill it with 64 step values. Does that not mean, that the
maximum red color will be only 50% intensity, because it goes only up to
32 steps, and the remaining 32 steps will never be used?
Or am I misunderstanding how fbdev colormap works?
> I don't set the alpha when it's required (no alpha => no alpha map)
>
> [PATCH] [compositor-fbdev]: DirectColor support
> The backend accepts to use TRUECOLOR and DIRECTCOLOR which are similares.
> DIRECTCOLOR has better results if the application applies a Colors map
> before to use it.
> The colors map is just a list of gradients for each colors and alpha.
>
> ---
> src/compositor-fbdev.c | 43 ++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> index 9c3d17e..c966d5a 100644
> --- a/src/compositor-fbdev.c
> +++ b/src/compositor-fbdev.c
> @@ -203,6 +203,43 @@ finish_frame_handler(void *data)
> return 1;
> }
>
> +static int
> +set_cmap(int fd, struct fb_var_screeninfo *vinfo)
> +{
> +struct fb_cmap cmap;
> +uint16_t *colors;
> +int i;
> +int rcols = 1 << vinfo->red.length;
> +int gcols = 1 << vinfo->green.length;
> +int bcols = 1 << vinfo->blue.length;
> +
> +memset(&cmap, 0, sizeof(cmap));
> +
> +/* Make our palette the length of the deepest color */
> +int cols = (rcols > gcols ? rcols : gcols);
> +cols = (cols > bcols ? cols : bcols);
> +
> +colors = malloc(sizeof(uint16_t) * cols);
> +if (!colors) return -1;
> +
> +for (i = 0; i < rcols; i++)
> +colors[i] = (UINT16_MAX / (rcols - 1)) * i;
IOW, should this divisor not be per channel, instead of using the same
for all channels?
In fact, you are using rcols in the divisor here, so if cols > rcols...
no wait...
> +
> +cmap.start = 0;
> +cmap.len = cols;
Here you use cols, but the loop uses rcols. How does this make sense?
> +cmap.red = colors;
> +cmap.blue = colors;
> +cmap.green = colors;
> +if (vinfo->transp.length)
> +cmap.transp = colors;
> +else
> +cmap.transp = NULL;
> +ioctl(fd, FBIOPUTCMAP, &cmap);
> +
> +free(colors);
> +return 0;
> +}
> +
> static pixman_format_code_t
> calculate_pixman_format(struct fb_var_screeninfo *vinfo,
> struct fb_fix_screeninfo *finfo)
> @@ -242,7 +279,8 @@ calculate_pixman_format(struct fb_var_screeninfo *vinfo,
> return 0;
>
> /* We only handle true-colour frame buffers at the moment. */
> -if (finfo->visual != FB_VISUAL_TRUECOLOR || vinfo->grayscale != 0)
> +if (!(finfo->visual == FB_VISUAL_TRUECOLOR || finfo->visual ==
> FB_VISUAL_DIRECTCOLOR)
> +|| vinfo->grayscale != 0)
> return 0;
>
> /* We only support formats with MSBs on the left. */
> @@ -325,6 +363,9 @@ fbdev_query_screen_info(struct fbdev_output *output,
> int fd,
> info->pixel_format = calculate_pixman_format(&varinfo, &fixinfo);
> info->refresh_rate = calculate_refresh_rate(&varinfo);
>
> +if (fixinfo.visual == FB_VISUAL_DIRECTCOLOR)
> +set_cmap(fd, &varinfo);
> +
> if (info->pixel_format == 0) {
> weston_log("Frame buffer uses an unsupported format.\n");
> return -1;
The last two hunks look good now.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH]: mtdev could be disabled at configuration
On Tue, 11 Jun 2013 15:53:42 +0200
Marc Chalain wrote:
> OK I used macro instead inline function. It's the same for the compiler (in
> this case).
> evdev: add --disable-mtdev option to configure and bypass the mtdev
> functions when the library is not available.
>
> ---
> configure.ac | 17 ++---
> src/evdev.c |9 -
> 2 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index b625221..2bdff35 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -132,7 +132,7 @@ AC_ARG_ENABLE(drm-compositor, [
> --enable-drm-compositor],,
> AM_CONDITIONAL(ENABLE_DRM_COMPOSITOR, test x$enable_drm_compositor = xyes
> -a x$enable_egl = xyes)
> if test x$enable_drm_compositor = xyes -a x$enable_egl = xyes; then
>AC_DEFINE([BUILD_DRM_COMPOSITOR], [1], [Build the DRM compositor])
> - PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm
> mtdev >= 1.1.0])
> + PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm])
> fi
>
>
> @@ -161,7 +161,7 @@ AM_CONDITIONAL(ENABLE_RPI_COMPOSITOR, test
> "x$enable_rpi_compositor" = "xyes")
> have_bcm_host="no"
> if test "x$enable_rpi_compositor" = "xyes"; then
>AC_DEFINE([BUILD_RPI_COMPOSITOR], [1], [Build the compositor for
> Raspberry Pi])
> - PKG_CHECK_MODULES(RPI_COMPOSITOR, [libudev >= 136 mtdev >= 1.1.0])
> + PKG_CHECK_MODULES(RPI_COMPOSITOR, [libudev >= 136])
>PKG_CHECK_MODULES(RPI_BCM_HOST, [bcm_host],
> [have_bcm_host="yes"
> AC_DEFINE([HAVE_BCM_HOST], [1], [have Raspberry Pi
> BCM headers])],
> @@ -176,7 +176,7 @@ AM_CONDITIONAL([ENABLE_FBDEV_COMPOSITOR],
> [test x$enable_fbdev_compositor = xyes])
> AS_IF([test x$enable_fbdev_compositor = xyes], [
>AC_DEFINE([BUILD_FBDEV_COMPOSITOR], [1], [Build the fbdev compositor])
> - PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev >= 136 mtdev >= 1.1.0])
> + PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev >= 136 ])
> ])
>
> AC_ARG_ENABLE([rdp-compositor], [ --enable-rdp-compositor],,
> @@ -203,6 +203,17 @@ PKG_CHECK_MODULES(WEBP, [libwebp], [have_webp=yes],
> [have_webp=no])
> AS_IF([test "x$have_webp" = "xyes"],
>[AC_DEFINE([HAVE_WEBP], [1], [Have webp])])
>
> +AC_ARG_ENABLE(mtdev,
> + AS_HELP_STRING([--disable-mtdev],
> + [do not support multitouch library
> libmtdev]),,
> + enable_mtdev=auto)
> +AM_CONDITIONAL(ENABLE_MTDEV, test "x$enable_mtdev" = "xyes")
> +if test "x$enable_mtdev" != "xno"; then
> +PKG_CHECK_MODULES(MTDEV, [mtdev >= 1.1.0], [have_mtdev=yes],
> [have_mtdev=no])
> +AS_IF([test "x$have_mtdev" = "xyes"],
> + [AC_DEFINE([HAVE_MTDEV], [1], [Have Multitouch device support])])
> +fi
> +
> AC_CHECK_LIB([jpeg], [jpeg_CreateDecompress], have_jpeglib=yes)
> if test x$have_jpeglib = xyes; then
>JPEG_LIBS="-ljpeg"
> diff --git a/src/evdev.c b/src/evdev.c
> index 122a2d9..b2a5eba 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -27,7 +27,15 @@
> #include
> #include
> #include
> +#ifdef HAVE_MTDEV
> #include
> +#else
> +struct mtdev
> +{ int none;};
> +#define mtdev_close_delete(...) do{}while(0)
> +#define mtdev_get(...) 0
> +#define mtdev_new_open(...) NULL
Did you try to run this?
To me it looks like the above will trigger the error "mtdev failed to
open" for every MT device, instead of quietly doing the right thing.
That's why my example did not override mtdev_new_open(), I intended to
leave that one #ifdef there.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [fbdev_backend]: support of DIRECTCOLOR Frame buffer
Theoretically you have right.
But the pixel formats are defined to contains the same amounts of values
for each colors except for 16bpp format (r5g6b5 and b5g6r5 one value more
for green) and the alpha. My code is optimized for a lot of cases.
For the use of rcols instead cols, you have right. It's a mistake.
Sorry "git send-email" fails on my computer (I think it's come from the
proxy).
[PATCH] fbdev: directcolor support
The backend accepts to use TRUECOLOR and DIRECTCOLOR which are similares.
DIRECTCOLOR has better results if the application applies a Colors
map before to use it.
The colors map is just a list of gradients for each colors and alpha.
---
src/compositor-fbdev.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 9c3d17e..7a3374e 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -203,6 +203,43 @@ finish_frame_handler(void *data)
return 1;
}
+static int
+set_cmap(int fd, struct fb_var_screeninfo *vinfo)
+{
+struct fb_cmap cmap;
+uint16_t *colors;
+int i;
+int rcols = 1 << vinfo->red.length;
+int gcols = 1 << vinfo->green.length;
+int bcols = 1 << vinfo->blue.length;
+
+memset(&cmap, 0, sizeof(cmap));
+
+/* Make our palette the length of the deepest color */
+int cols = (rcols > gcols ? rcols : gcols);
+cols = (cols > bcols ? cols : bcols);
+
+colors = malloc(sizeof(uint16_t) * cols);
+if (!colors) return -1;
+
+for (i = 0; i < cols; i++)
+colors[i] = (UINT16_MAX / (cols - 1)) * i;
+
+cmap.start = 0;
+cmap.len = cols;
+cmap.red = colors;
+cmap.blue = colors;
+cmap.green = colors;
+if (vinfo->transp.length)
+cmap.transp = colors;
+else
+cmap.transp = NULL;
+ioctl(fd, FBIOPUTCMAP, &cmap);
+
+free(colors);
+return 0;
+}
+
static pixman_format_code_t
calculate_pixman_format(struct fb_var_screeninfo *vinfo,
struct fb_fix_screeninfo *finfo)
@@ -242,7 +279,8 @@ calculate_pixman_format(struct fb_var_screeninfo *vinfo,
return 0;
/* We only handle true-colour frame buffers at the moment. */
-if (finfo->visual != FB_VISUAL_TRUECOLOR || vinfo->grayscale != 0)
+if (!(finfo->visual == FB_VISUAL_TRUECOLOR || finfo->visual ==
FB_VISUAL_DIRECTCOLOR)
+|| vinfo->grayscale != 0)
return 0;
/* We only support formats with MSBs on the left. */
@@ -325,6 +363,9 @@ fbdev_query_screen_info(struct fbdev_output *output,
int fd,
info->pixel_format = calculate_pixman_format(&varinfo, &fixinfo);
info->refresh_rate = calculate_refresh_rate(&varinfo);
+if (fixinfo.visual == FB_VISUAL_DIRECTCOLOR)
+set_cmap(fd, &varinfo);
+
if (info->pixel_format == 0) {
weston_log("Frame buffer uses an unsupported format.\n");
return -1;
--
1.7.9.5
2013/6/11 Pekka Paalanen
> On Tue, 11 Jun 2013 15:15:29 +0200
> Marc Chalain wrote:
>
> > Hello,
> > OK this patch now checks FB_VISUAL_DIRECTCOLOR twice but set the cmap
> > inside the fbdev_query_screen_info function.
> > I use "malloc" instead "table" declaration because it takes less memory
> and
> > it's used only once, it's useless to be faster.
> > After I set the same values for each colors, because it's a default map.
> To
> > set more finely we have to know the screen and it's capabilities.
>
> What I meant is, if rcols = 32 and gcols = 64, you allocate a 64-long
> array, and fill it with 64 step values. Does that not mean, that the
> maximum red color will be only 50% intensity, because it goes only up to
> 32 steps, and the remaining 32 steps will never be used?
>
> Or am I misunderstanding how fbdev colormap works?
>
> > I don't set the alpha when it's required (no alpha => no alpha map)
> >
> > [PATCH] [compositor-fbdev]: DirectColor support
> > The backend accepts to use TRUECOLOR and DIRECTCOLOR which are similares.
> > DIRECTCOLOR has better results if the application applies a Colors map
> > before to use it.
> > The colors map is just a list of gradients for each colors and alpha.
> >
> > ---
> > src/compositor-fbdev.c | 43
> ++-
> > 1 file changed, 42 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> > index 9c3d17e..c966d5a 100644
> > --- a/src/compositor-fbdev.c
> > +++ b/src/compositor-fbdev.c
> > @@ -203,6 +203,43 @@ finish_frame_handler(void *data)
> > return 1;
> > }
> >
> > +static int
> > +set_cmap(int fd, struct fb_var_screeninfo *vinfo)
> > +{
> > +struct fb_cmap cmap;
> > +uint16_t *colors;
> > +int i;
> > +int rcols = 1 << vinfo->red.length;
> > +int gcols = 1 << vinfo->green.length;
> > +int bcols = 1 << vinfo->blue.length;
> > +
> > +memset(&cmap, 0, sizeof(cmap));
> > +
> > +/* Make our palette the length of the deepest color */
> > +int cols = (rcol
Re: [compositor] idle-time configuration inside weston.ini
idle-time: manpage update --- man/weston.ini.man |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/man/weston.ini.man b/man/weston.ini.man index c3e5747..ae94d9b 100644 --- a/man/weston.ini.man +++ b/man/weston.ini.man @@ -103,8 +103,10 @@ directory are: .BR xwayland.so .fi .RE -.RS .PP +.TP 7 +.BI "idle-time=" value +sets time before to fall in idle as --idle-time argument (integer). .SH "SHELL SECTION" The -- 1.7.9.5 2013/6/11 Pekka Paalanen > On Tue, 11 Jun 2013 14:43:46 +0200 > Marc Chalain wrote: > > > You have right, it's the smallest of my patches, and the worst. > > > > [PATCH] [compositor]: add "idle-time" entry support in "core" > > section of weston.ini > > > > --- > > src/compositor.c |2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/src/compositor.c b/src/compositor.c > > index 099600d..2002812 100644 > > --- a/src/compositor.c > > +++ b/src/compositor.c > > @@ -3277,6 +3277,8 @@ int main(int argc, char *argv[]) > > section = weston_config_get_section(config, "core", NULL, NULL); > > weston_config_section_get_string(section, "modules", > > &modules, "desktop-shell.so"); > > +weston_config_section_get_int(section, "idle-time", > > + &idle_time, idle_time); > > > > backend_init = load_module(backend, "backend_init"); > > if (!backend_init) > > I think that should work. What about the man pages? > > > Thanks, > pq > 0005-idle-time-manpage-update.patch Description: Binary data ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] doc: Add a small contributing guide
Document what we expect in terms of commit messages and coding style.
New contributors are usually unaware of this, so it is good to have a
document to point them too.
---
I probably haven't captured everything here and some might be my opinion
and not a rule, but I think it would be good to have this and edit/expand
as needed.
Cheers,
Ander
---
doc/Contributing | 83 ++
doc/Makefile.am |2 ++
2 files changed, 85 insertions(+)
create mode 100644 doc/Contributing
diff --git a/doc/Contributing b/doc/Contributing
new file mode 100644
index 000..df94e11
--- /dev/null
+++ b/doc/Contributing
@@ -0,0 +1,83 @@
+= Contributing to Wayland =
+
+== Sending patches ==
+
+Patches should be sent to wayland-devel@lists.freedesktop.org, using
+git send-email. See git's documentation for help [1].
+
+The first line of a commit message should contain a prefix indicating
+what part is affected by the patch followed by one sentence that
+describes the change. For examples:
+
+protocol: Support scaled outputs and surfaces
+
+and
+
+doc: generate server documentation from XML too.
+
+If in doubt what prefix to use, look at other commits that change the
+same file(s) as the patch being sent.
+
+The body of the commit message should describe what the patch changes
+and why, and also note any particular side effects. This shouldn't be
+empty on most of the cases. It shouldn't take a lot of effort to write
+a commit message for an obvious change, so an empty commit message
+body is only acceptable if the questions "What?" and "Why" are already
+answered on the one-line summary.
+
+The lines of the commit message should have at most 76 characters, to
+cope with the way git log presents them.
+
+See [2] for a recommend reading on writing commit messages.
+
+== Coding style ==
+
+You should follow the style of the file you're editing. In general, we
+try to follow the rules below.
+
+- indent with tabs, and a tab is always 8 characters wide
+- opening braces are on the same line as the if statement;
+- no braces in an if-body with just one statement;
+- if one of the branches of an if-else codition has braces, than the
+ other branch should also have braces;
+- there is always an empty line between variable declarations and the
+ code;
+
+static int
+my_function(void)
+{
+ int a = 0;
+
+ if (a)
+ b();
+ else
+ c();
+
+ if (a) {
+ b();
+ c();
+ } else {
+ d();
+ }
+}
+
+- lines should be less than 80 characters wide;
+- when breaking lines with functions calls, the parameters are aligned
+ with the opening parenthesis;
+- when assigning a variable with the result of a function call, if the
+ line would be longer we break it around the equal '=' sign if it makes
+ sense;
+
+ long_variable_name =
+ function_with_a_really_long_name(parameter1, parameter2,
+parameter3, parameter4);
+
+ x = function_with_a_really_long_name(parameter1, parameter2,
+parameter3, parameter4);
+
+== References ==
+
+ [1] http://git-scm.com/documentation
+
+ [2] http://who-t.blogspot.de/2009/12/on-commit-messages.html
+
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 1efd3e2..14637af 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -1 +1,3 @@
SUBDIRS = doxygen publican man
+
+EXTRA_DIST = Contributing
--
1.7.10.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] doc: Add a small contributing guide
On Tue, 11 Jun 2013 18:21:32 +0300
Ander Conselvan de Oliveira wrote:
> Document what we expect in terms of commit messages and coding style.
> New contributors are usually unaware of this, so it is good to have a
> document to point them too.
> ---
>
> I probably haven't captured everything here and some might be my opinion
> and not a rule, but I think it would be good to have this and edit/expand
> as needed.
>
> Cheers,
> Ander
>
> ---
> doc/Contributing | 83
> ++
> doc/Makefile.am |2 ++
> 2 files changed, 85 insertions(+)
> create mode 100644 doc/Contributing
>
> diff --git a/doc/Contributing b/doc/Contributing
> new file mode 100644
> index 000..df94e11
> --- /dev/null
> +++ b/doc/Contributing
> @@ -0,0 +1,83 @@
> += Contributing to Wayland =
> +
> +== Sending patches ==
> +
> +Patches should be sent to wayland-devel@lists.freedesktop.org, using
> +git send-email. See git's documentation for help [1].
> +
> +The first line of a commit message should contain a prefix indicating
> +what part is affected by the patch followed by one sentence that
> +describes the change. For examples:
> +
> +protocol: Support scaled outputs and surfaces
> +
> +and
> +
> +doc: generate server documentation from XML too.
> +
> +If in doubt what prefix to use, look at other commits that change the
> +same file(s) as the patch being sent.
> +
> +The body of the commit message should describe what the patch changes
> +and why, and also note any particular side effects. This shouldn't be
> +empty on most of the cases. It shouldn't take a lot of effort to write
> +a commit message for an obvious change, so an empty commit message
> +body is only acceptable if the questions "What?" and "Why" are already
> +answered on the one-line summary.
> +
> +The lines of the commit message should have at most 76 characters, to
> +cope with the way git log presents them.
> +
> +See [2] for a recommend reading on writing commit messages.
> +
> +== Coding style ==
> +
> +You should follow the style of the file you're editing. In general, we
> +try to follow the rules below.
> +
> +- indent with tabs, and a tab is always 8 characters wide
> +- opening braces are on the same line as the if statement;
> +- no braces in an if-body with just one statement;
> +- if one of the branches of an if-else codition has braces, than the
> + other branch should also have braces;
> +- there is always an empty line between variable declarations and the
> + code;
> +
> +static int
> +my_function(void)
> +{
> + int a = 0;
> +
> + if (a)
> + b();
> + else
> + c();
> +
> + if (a) {
> + b();
> + c();
> + } else {
> + d();
> + }
> +}
> +
> +- lines should be less than 80 characters wide;
> +- when breaking lines with functions calls, the parameters are aligned
> + with the opening parenthesis;
> +- when assigning a variable with the result of a function call, if the
> + line would be longer we break it around the equal '=' sign if it makes
> + sense;
> +
> + long_variable_name =
> + function_with_a_really_long_name(parameter1, parameter2,
> + parameter3, parameter4);
> +
> + x = function_with_a_really_long_name(parameter1, parameter2,
> + parameter3, parameter4);
> +
> +== References ==
> +
> + [1] http://git-scm.com/documentation
> +
> + [2] http://who-t.blogspot.de/2009/12/on-commit-messages.html
> +
> diff --git a/doc/Makefile.am b/doc/Makefile.am
> index 1efd3e2..14637af 100644
> --- a/doc/Makefile.am
> +++ b/doc/Makefile.am
> @@ -1 +1,3 @@
> SUBDIRS = doxygen publican man
> +
> +EXTRA_DIST = Contributing
Yes! \o/
One addendum in style could be the function definition:
attributes and return type
function_name(args, ...)
{
code;
}
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: The way to use system cursor and custom(client) cursor
> -Original Message-
> From: Pekka Paalanen [mailto:ppaala...@gmail.com]
> Sent: Tuesday, June 11, 2013 12:25 AM
> To: Elvis Lee ("이광웅")
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: The way to use system cursor and custom(client) cursor
>
> On Mon, 10 Jun 2013 10:52:34 -0700
> Elvis Lee(이광웅) wrote:
>
> > > -Original Message-
> > > From:
> > > wayland-devel-bounces+kwangwoong.lee=lge@lists.freedesktop.org
> > > [mailto:wayland-devel-bounces+kwangwoong.lee=lge.com@lists.freedeskt
> > > op.org]
> > > On Behalf Of Pekka Paalanen
> > > Sent: Sunday, June 09, 2013 11:03 PM
> > > To: Elvis Lee (__)
> > > Cc: wayland-devel@lists.freedesktop.org
> > > Subject: Re: The way to use system cursor and custom(client) cursor
> > >
> > > On Sun, 9 Jun 2013 16:01:48 -0700
> > > Elvis Lee(__) wrote:
> > >
> > > > Hello.
> > > >
> > > >
> > > >
> > > > I feel unnatural to implement custom cursor scenario. Here is a
> question.
> > > >
> > > > How does a client request compositor to use system cursor?
> > > >
> > > >
> > > >
> > > > The system cursor means a current default cursor for compositor.
> > > >
> > > > Currently, client should know about the system cursor in order to
> > > > use it as parameter of wl_pointer.set_cursor.
> > > >
> > > > Otherwise, cursor surface should be destroyed to request
> > > > compositor a rollback to system cursor from custom cursor.
> > > >
> > > >
> > > >
> > > > I think it¡¯s enough to detach buffer from cursor surface for
> > > > hiding the cursor.
> > > >
> > > > And set_cursor(null surface) can be used to request to stop using
> > > > custom cursor. (rollback)
> > > >
> > > >
> > > >
> > > > Here are some states and protocols.
> > > >
> > > >
> > > >
> > > > 1. System cursor -> Custom cursor
> > > >
> > > > A. set_cursor(cursor_surface)
> > > >
> > > > B. cursor_surface.attach(buffer for custom image)
> > > >
> > > > C. cursor_surface.damage
> > > >
> > > > D. cursor_surface.commit
> > > >
> > > >
> > > >
> > > > 2. Custom cursor -> System cursor
> > > >
> > > > A. set_cursor(null surface)
> > > >
> > > >
> > > >
> > > > 3. Custom cursor -> Hide Cursor
> > > >
> > > > A. set_cursor(cursor_surface) (can be omitted if it is already
> set)
> > > >
> > > > B. cursor_surface.attach(null buffer)
> > > >
> > > > C. cursor_surface.commit
> > > >
> > > >
> > > >
> > > > 4. System cursor -> Hide Cursor
> > > >
> > > > A. set_cursor(cursor_surface)
> > > >
> > > > B. cursor_surface.attach(null buffer) (can be omitted if it is
> > > already
> > > > detached)
> > > >
> > > > C. cursor_surface.commit
> > > >
> > > >
> > > >
> > > > I think this can cover up a scenario when pointer enters into a
> > > > surface of client.
> > > >
> > > > If there is no specific cursor for client to want when pointer
> > > > enters, it¡¯s enough to request set_cursor(null).
> > > >
> > > >
> > > >
> > > > Is this approach possible? I want to listen your opinions.
> > >
> > > Hi Elvis,
> > >
> > > do I understand right, that you would like to add the concept of a
> > > system cursor?
> > >
> > > I guess it would be possible, but why?
> > >
> > > It seems the system cursor you propose would be one arbitrary cursor
> > > without any meaning. When and why would applications ever want to use
> it?
> > >
> > > The compositor usually cannot, and there is no need to, switch to a
> > > system cursor on its own, so it would always be requested by a client.
> > > I can understand applications wanting a specific cursor, or no
> > > cursor, but what would be the purpose of a system cursor?
> > >
> > > If you also consider cursor themes, the system cursor would be from
> > > one theme. An application using a system cursor would need to use
> > > the same theme for its other cursors to look consistent.
> > >
> > > We already have libwayland-cursor to help you load a cursor theme,
> > > so using a proper cursor should not be too hard.
> > >
> >
> > Hi, Pekka.
> >
> > Thanks for your opinion.
> >
> > Possibly, The word 'system cursor' can attract over attention.
> > As you said, it's just one of the cursor themes.
> >
> >
> > It might be unclear for my explain. Here is a simple scenario.
> > Compositor can own its cursor without client or with minimized client or
> outside focused client window.
> > And the cursor is configurable.
> > Compositor stared with blue cursor, then user changes it to red one.
> > After launching a client, the client override the cursor with specific
> one.
> > After a while, client want to use the cursor which is used by compositor
> just before.
>
> What do you mean by the compositor's cursor?
>
> Like krh explained to Bill, in Weston, there are no noticeable surfaces
> owned by the compositor. Everything, including the background color fill,
> are owned by some client. That client gets pointer enter events and sets
> the cursor on enter, as any client does. A scenario or screen areas
> without *a
Re: [fbdev_backend]: support of DIRECTCOLOR Frame buffer
On Tue, 11 Jun 2013 16:31:17 +0200
Marc Chalain wrote:
> Theoretically you have right.
> But the pixel formats are defined to contains the same amounts of values
> for each colors except for 16bpp format (r5g6b5 and b5g6r5 one value more
> for green) and the alpha. My code is optimized for a lot of cases.
> For the use of rcols instead cols, you have right. It's a mistake.
So, you think it's ok to be presumably broken on 565 formats?
The fix really is not that hard, and the "optimizations" here are
totally insignificant.
> Sorry "git send-email" fails on my computer (I think it's come from the
> proxy).
There are other ways to send email without messing up whitespace,
any of them will do. Take a look at other people's patch series on
the mailing list, how they look, and try to replicate that.
Until then, I think I've reviewed enough here for now.
Btw. the idle-time man page patch should be part of the same commit
as the idle-time config implementation.
Thanks,
pq
> [PATCH] fbdev: directcolor support
> The backend accepts to use TRUECOLOR and DIRECTCOLOR which are similares.
> DIRECTCOLOR has better results if the application applies a Colors
> map before to use it.
> The colors map is just a list of gradients for each colors and alpha.
>
> ---
> src/compositor-fbdev.c | 43 ++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> index 9c3d17e..7a3374e 100644
> --- a/src/compositor-fbdev.c
> +++ b/src/compositor-fbdev.c
> @@ -203,6 +203,43 @@ finish_frame_handler(void *data)
> return 1;
> }
>
> +static int
> +set_cmap(int fd, struct fb_var_screeninfo *vinfo)
> +{
> +struct fb_cmap cmap;
> +uint16_t *colors;
> +int i;
> +int rcols = 1 << vinfo->red.length;
> +int gcols = 1 << vinfo->green.length;
> +int bcols = 1 << vinfo->blue.length;
> +
> +memset(&cmap, 0, sizeof(cmap));
> +
> +/* Make our palette the length of the deepest color */
> +int cols = (rcols > gcols ? rcols : gcols);
> +cols = (cols > bcols ? cols : bcols);
> +
> +colors = malloc(sizeof(uint16_t) * cols);
> +if (!colors) return -1;
> +
> +for (i = 0; i < cols; i++)
> +colors[i] = (UINT16_MAX / (cols - 1)) * i;
> +
> +cmap.start = 0;
> +cmap.len = cols;
> +cmap.red = colors;
> +cmap.blue = colors;
> +cmap.green = colors;
> +if (vinfo->transp.length)
> +cmap.transp = colors;
> +else
> +cmap.transp = NULL;
> +ioctl(fd, FBIOPUTCMAP, &cmap);
> +
> +free(colors);
> +return 0;
> +}
> +
> static pixman_format_code_t
> calculate_pixman_format(struct fb_var_screeninfo *vinfo,
> struct fb_fix_screeninfo *finfo)
> @@ -242,7 +279,8 @@ calculate_pixman_format(struct fb_var_screeninfo *vinfo,
> return 0;
>
> /* We only handle true-colour frame buffers at the moment. */
> -if (finfo->visual != FB_VISUAL_TRUECOLOR || vinfo->grayscale != 0)
> +if (!(finfo->visual == FB_VISUAL_TRUECOLOR || finfo->visual ==
> FB_VISUAL_DIRECTCOLOR)
> +|| vinfo->grayscale != 0)
> return 0;
>
> /* We only support formats with MSBs on the left. */
> @@ -325,6 +363,9 @@ fbdev_query_screen_info(struct fbdev_output *output,
> int fd,
> info->pixel_format = calculate_pixman_format(&varinfo, &fixinfo);
> info->refresh_rate = calculate_refresh_rate(&varinfo);
>
> +if (fixinfo.visual == FB_VISUAL_DIRECTCOLOR)
> +set_cmap(fd, &varinfo);
> +
> if (info->pixel_format == 0) {
> weston_log("Frame buffer uses an unsupported format.\n");
> return -1;
> --
> 1.7.9.5
>
>
>
>
> 2013/6/11 Pekka Paalanen
>
> > On Tue, 11 Jun 2013 15:15:29 +0200
> > Marc Chalain wrote:
> >
> > > Hello,
> > > OK this patch now checks FB_VISUAL_DIRECTCOLOR twice but set the cmap
> > > inside the fbdev_query_screen_info function.
> > > I use "malloc" instead "table" declaration because it takes less memory
> > and
> > > it's used only once, it's useless to be faster.
> > > After I set the same values for each colors, because it's a default map.
> > To
> > > set more finely we have to know the screen and it's capabilities.
> >
> > What I meant is, if rcols = 32 and gcols = 64, you allocate a 64-long
> > array, and fill it with 64 step values. Does that not mean, that the
> > maximum red color will be only 50% intensity, because it goes only up to
> > 32 steps, and the remaining 32 steps will never be used?
> >
> > Or am I misunderstanding how fbdev colormap works?
> >
> > > I don't set the alpha when it's required (no alpha => no alpha map)
> > >
> > > [PATCH] [compositor-fbdev]: DirectColor support
> > > The backend accepts to use TRUECOLOR and DIRECTCOLOR which are similares.
> > > DIRECTCOLOR has better results if the application applies a Colors map
> > > before to use it.
> > > The colors map is just a list of gradients for each colors and alpha.
> > >
> >
Re: minimized and stick windows
On Thu, Jun 6, 2013 at 3:50 PM, Kristian Høgsberg wrote: > On Tue, May 28, 2013 at 1:10 PM, Rafael Antognolli > wrote: >> On Thu, May 16, 2013 at 2:12 PM, Bill Spitzak wrote: >>> >>> >>> Pekka Paalanen wrote: >>> > For example the floating shared toolbox with 2 main windows. It should > only disappear when *both* main windows are minimized. You very conventiently removed my next sentence, where I already took this into account. - pq >>> >>> >>> Sorry, obviously I did not read very carefully: >>> >>> Actually, if you think about a multi-window application, minimize needs to work the same way, so that application can hide all relevant windows (but maybe not *all* windows). >>> >>> I think also it is important to note that the compositor cannot even hide >>> the window the minimize is for. This is because that hide should be in sync >>> with the hiding of other windows, so the client should do all of them. >> >> OK, so since what Khristian proposed was this: >> >> https://github.com/antognolli/wayland/commit/a94eb97fdf49c6e06b0b4e94f4b8c840602442db >> >> Can I start from it? It seems to me that it allows to cover the most >> important part mentioned here, which is the fact that weston will only >> send the minimize events and clients should have control over this. > > Looks fine, putting some code behind all this talk would be very welcome. Starting code here. Following are some comments. https://github.com/antognolli/wayland/commits/minimize https://github.com/antognolli/weston/commits/minimize I didn't add code for the events that ask state changes from the compositor, neither any code related to minimize yet. I tried to first change the current maximized surface type to be just another state, as suggested at some point in this thread. So, it ended up very hackish IMHO. In order to do that, when the surface type is set to maximized, I change it to set the maximized state instead, which is currently working correctly (from my tests). But when the surface type is set to anything else than maximized, I have to unset the maximized state, to keep the same behavior as before these changes. I need to know if I should follow this path, in which case I'll improve the above code (some refactory can take place), or if we should use another approach. Maybe the minimized state should be in fact another surface type, and we would only have states for things like always_on_top and sticky (and any other that may come next). Or maybe we can keep the same surface types that we had already, and just add minimized as a state. What are your opinions about this? PS: I'm sending the code as links to github since it's not a request to integrate it yet, but I can send it to the list as attached patches if it's preferable. PS2: I added the surface states as a bitmask, but since I didn't see something like that in the rest of the code, I can also change it to a simple enum. Regards, -- Rafael Antognolli ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] Handle SYN_DROPPED, filter keys with a bitmap
Since evdev keys are unreliable, they might randomly get dropped, such
as, on SYN_DROPPED. Even SYN_DROPPED is sometimes not delivered.
Clients, compositor are not able to recover from duplicate press/release.
This fixes this bug, thereby making the compositor and clients useable
even under critical system conditions such as, but not limited to, high
system load, device malfunction. This improves reliability.
Every device contains a key bitmap. Each passing key press/release
is checked and recorded. Duplicated presses, releases are handled by
emitting the opposite type event in between (the time is faked -1 time unit).
This is a last resort solution and happens only very rarely.
When a SYN_DROPPED is detected:
1 wait until after the next SYN_REPORT.
2 Ask the kernel for the actual state of buttons
3 Compare the buttons with the internal key bitmap, to see what changed.
4 Send each different key via notify to the compositor, with timestamp.
5 Update the internal key bitmap to match the kernel's
Disadvantages of this approach
Each evdev device consumes 96 bytes more memory.
Table lookup+bit toggle for almost key.
Don't know the timestamp of missing keys.
The key_notify from kernel bitmap compare occurs later the real missing event.
That's a timestamp issue.
---
src/evdev-touchpad.c | 51 ++-
src/evdev.c | 176 ++
src/evdev.h | 35 +++---
3 files changed, 208 insertions(+), 54 deletions(-)
diff --git a/src/evdev-touchpad.c b/src/evdev-touchpad.c
index a21ae0b..890ddad 100644
--- a/src/evdev-touchpad.c
+++ b/src/evdev-touchpad.c
@@ -533,6 +533,26 @@ on_release(struct touchpad_dispatch *touchpad)
push_fsm_event(touchpad, FSM_EVENT_RELEASE);
}
+struct evdev_dispatch_interface touchpad_interface;
+struct evdev_dispatch_interface touchpad_syn_drop_interface;
+
+static inline void
+process_syn(struct touchpad_dispatch *touchpad,
+struct evdev_device *device,
+struct input_event *e, uint32_t time)
+{
+ switch (e->code) {
+ case SYN_DROPPED:
+ if (device->dispatch->interface == &touchpad_interface)
+ device->dispatch->interface =
&touchpad_syn_drop_interface;
+ break;
+ case SYN_REPORT:
+ default:
+ touchpad->event_mask |= TOUCHPAD_EVENT_REPORT;
+ break;
+ }
+}
+
static inline void
process_absolute(struct touchpad_dispatch *touchpad,
struct evdev_device *device,
@@ -588,7 +608,7 @@ process_key(struct touchpad_dispatch *touchpad,
case BTN_FORWARD:
case BTN_BACK:
case BTN_TASK:
- notify_button(device->seat,
+ notify_button(device->seat,
time, e->code,
e->value ? WL_POINTER_BUTTON_STATE_PRESSED :
WL_POINTER_BUTTON_STATE_RELEASED);
@@ -634,8 +654,7 @@ touchpad_process(struct evdev_dispatch *dispatch,
switch (e->type) {
case EV_SYN:
- if (e->code == SYN_REPORT)
- touchpad->event_mask |= TOUCHPAD_EVENT_REPORT;
+ process_syn(touchpad, device, e, time);
break;
case EV_ABS:
process_absolute(touchpad, device, e);
@@ -664,6 +683,32 @@ struct evdev_dispatch_interface touchpad_interface = {
touchpad_destroy
};
+static void
+touchpad_syn_drop_process(struct evdev_dispatch *dispatch,
+struct evdev_device *device,
+struct input_event *event,
+uint32_t time)
+{
+ if ((event->code != EV_SYN) || (event->code != SYN_REPORT))
+ return;
+
+ if (device->dispatch->interface == &touchpad_syn_drop_interface)
+ device->dispatch->interface = &touchpad_interface;
+
+ evdev_keys_state_sync(device, time);
+}
+
+static void
+touchpad_syn_drop_destroy(struct evdev_dispatch *dispatch)
+{
+ free(dispatch);
+}
+
+struct evdev_dispatch_interface touchpad_syn_drop_interface = {
+ touchpad_syn_drop_process,
+ touchpad_syn_drop_destroy
+};
+
static int
touchpad_init(struct touchpad_dispatch *touchpad,
struct evdev_device *device)
diff --git a/src/evdev.c b/src/evdev.c
index 122a2d9..8058c8f 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -62,13 +62,29 @@ evdev_led_update(struct evdev_device *device, enum
weston_led leds)
(void)i; /* no, we really don't care about the return value */
}
+struct evdev_dispatch_interface fallback_interface;
+struct evdev_dispatch_interface syn_drop_interface;
+
static inline void
-evdev_process_key(struct evdev_device *device, struct input_event *e, int time)
+evdev_process_syn(struct evdev_device *device, struct input_event *e)
{
- if (e->value == 2)
- return;
-
switch (e->code) {
+ case SYN_DROPPED:
+ if (d
[PATCH 2/2] weston input: Add the key states counters
This fixes the compositor, so that it delivers the correct events, when attached
multiple keyboards to the same seat. This is tested under the evdev backend,
perhaps it works under multiseat X.
The way to verify this:
1. press A on keyboard 1
2. press A on keyboard 2
3. release A on keyboard 1
4. release A on keyboard 2
The actual sequence:
[2134420.1337] -> wl_keybo...@39.key(2316, 899782584, 30, 1)
[2134421.1337] -> wl_keybo...@39.key(2316, 899782584, 30, 1)
[2134422.1337] -> wl_keybo...@39.key(2316, 899782584, 30, 0)
[2134423.1337] -> wl_keybo...@39.key(2316, 899782584, 30, 0)
The correct sequence - after applying this patch:
[2134420.1337] -> wl_keybo...@39.key(2316, 899782584, 30, 1)
[2134423.1337] -> wl_keybo...@39.key(2316, 899782584, 30, 0)
The reason is, because the wl_keyboard device must from the client's
perspective act like single input device, as discussed.
---
src/compositor-wayland.c | 12 +-
src/compositor-x11.c | 17 +---
src/compositor.h |2 +
src/evdev.c | 28 -
src/evdev.h |6 +--
src/input.c | 104 +-
tests/weston-test.c |5 ++-
7 files changed, 125 insertions(+), 49 deletions(-)
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index f3a98a8..f46809e 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -529,11 +529,21 @@ input_handle_keyboard_enter(void *data,
struct wl_array *keys)
{
struct wayland_input *input = data;
+ struct wl_array key_states;
+ unsigned int *k_cnt;
+
+ wl_array_init(&key_states);
+ wl_array_add(&key_states, keys->size);
+ wl_array_for_each(k_cnt, &key_states) {
+ *k_cnt = 1;
+ }
/* XXX: If we get a modifier event immediately before the focus,
* we should try to keep the same serial. */
- notify_keyboard_focus_in(&input->base, keys,
+ notify_keyboard_focus_in(&input->base, keys, &key_states,
STATE_UPDATE_AUTOMATIC);
+
+ wl_array_release(&key_states);
}
static void
diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 5a0bcf0..a1e2b57 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -65,7 +65,6 @@ struct x11_compositor {
xcb_connection_t*conn;
xcb_screen_t*screen;
xcb_cursor_t null_cursor;
- struct wl_array keys;
struct wl_event_source *xcb_source;
struct xkb_keymap *xkb_keymap;
unsigned int has_xkb;
@@ -1181,6 +1180,8 @@ static int
x11_compositor_handle_event(int fd, uint32_t mask, void *data)
{
struct x11_compositor *c = data;
+ struct wl_array keys;
+ struct wl_array key_states;
struct x11_output *output;
xcb_generic_event_t *event, *prev;
xcb_client_message_event_t *client_message;
@@ -1225,6 +1226,7 @@ x11_compositor_handle_event(int fd, uint32_t mask, void
*data)
key_release->detail - 8,
WL_KEYBOARD_KEY_STATE_RELEASED,
STATE_UPDATE_AUTOMATIC);
+
free(prev);
prev = NULL;
break;
@@ -1233,13 +1235,16 @@ x11_compositor_handle_event(int fd, uint32_t mask, void
*data)
case XCB_FOCUS_IN:
assert(response_type == XCB_KEYMAP_NOTIFY);
keymap_notify = (xcb_keymap_notify_event_t *) event;
- c->keys.size = 0;
+ wl_array_init(&keys);
+ wl_array_init(&key_states);
for (i = 0; i < ARRAY_LENGTH(keymap_notify->keys) * 8;
i++) {
set = keymap_notify->keys[i >> 3] &
(1 << (i & 7));
if (set) {
- k = wl_array_add(&c->keys, sizeof *k);
+ k = wl_array_add(&keys, sizeof *k);
*k = i;
+ k = wl_array_add(&key_states, sizeof
*k);
+ *k = 1;
}
}
@@ -1247,9 +1252,12 @@ x11_compositor_handle_event(int fd, uint32_t mask, void
*data)
* event, rather than with the focus event. I'm not
* sure of the exact semantics around it and whether
* we can ensure that we get both? */
- notify_keyboard_focus_in(&c->core_seat, &c->keys,
+ notify_keyboard_focus_in(&c->core_seat, &keys,
&key_states,
[PATCH] Wayland: Add how wl_keyboard represents more keyboards
This has been discussed. If the user wants to be able to track multiple keyboards, they need multiple seats. The enter keys attribute means it's pressed on one or multiple seat-attached keyboards. The keys never contains duplicate keys. --- protocol/wayland.xml | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index f3ba296..36265fc 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1384,7 +1384,8 @@ The wl_keyboard interface represents one or more keyboards - associated with a seat. + associated with a seat. The compositor acts as if there is one + keyboard. @@ -1408,7 +1409,8 @@ Notification that this seat's keyboard focus is on a certain - surface. + surface. The keys are currently depressed on one or multiple + seat-attached devices. The keys contain no duplicate items. @@ -1429,15 +1431,17 @@ - Describes the physical state of a key which provoked the key event. + Describes the new state of a key which provoked the key event. - + - A key was pressed or released. + A key was pressed first time or released the last time. + In case the same key code is, or has been held on multiple seat-attached devices, + no event is provoked. The time argument is a timestamp with millisecond granularity, with an undefined base. -- 1.7.10.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Things that killed my motivation to play with wayland
1) This mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=61919 make fails without C_INCLUDE_PATH set. It pretty much destroyed my build testing setup (I was build testing 46 related repos every few hours). I never managed to work out the obvious workaround of just setting C_INCLUDE_PATH for mesa builds (which I had working for another repo). I included the commit where the problem started. Three months ago. (Build test script I wrote: http://www.chaosreigns.com/code/buildtest/ ) 2) The XWayland segfault bug: https://bugs.freedesktop.org/show_bug.cgi?id=59983 This was the reason I stopped using weston as my primary UI at home in September. Tiago said he had a fix for it in one of his branches a long time ago, but I guess it wasn't compatible with the changes made to the plan to handle xwm. Blows my mind that this isn't the top priority of the project. I'm sure there's fine reasons. It would be nice to know what they are. 3) The state of cairo's build testing, particularly this bug: https://bugs.freedesktop.org/show_bug.cgi?id=62375 Cairo has a huge and glorious build test suite. But it looked very much to me like nobody could've gotten it to pass all tests in any subset in years. psychon was very helpful in tracking down and fixing problems. This one last bug was in the way of me being able to get a full subset of tests to pass, so I could automate running them reasonably. The maintainer of cairo, Chris Wilson, included a patch to fix it in a comment to that bug, but we haven't been able to get him to commit it, in three months. (Lots of stuff, including weston and gtk, are heavily dependent on cairo, which tends to break. Which isn't surprising with its unusable build tests. And the fact that the build test instructions specify a method that doesn't allow cairo-gl to be tested.) -- "Believe nothing, no matter where you read it or who has said it, even if I have said it, unless it agrees with your own reason and your own common sense." - Buddha, 563-483 B.C. http://www.ChaosReigns.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/3] xwm: Define SEND_EVENT_MASK and EVENT_TYPE macros to clarify xcb event type checks
---
src/xwayland/window-manager.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 366f2e0..a021c76 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -89,6 +89,9 @@ struct motif_wm_hints {
#define _NET_WM_MOVERESIZE_MOVE_KEYBOARD10 /* move via keyboard */
#define _NET_WM_MOVERESIZE_CANCEL 11 /* cancel operation */
+#define SEND_EVENT_MASK (0x80)
+#define EVENT_TYPE(event) ((event)->response_type & ~SEND_EVENT_MASK)
+
struct weston_wm_window {
struct weston_wm *wm;
xcb_window_t id;
@@ -748,7 +751,7 @@ weston_wm_handle_unmap_notify(struct weston_wm *wm,
xcb_generic_event_t *event)
if (our_resource(wm, unmap_notify->window))
return;
- if (unmap_notify->response_type & 0x80)
+ if (unmap_notify->response_type & SEND_EVENT_MASK)
/* We just ignore the ICCCM 4.1.4 synthetic unmap notify
* as it may come in after we've destroyed the window. */
return;
@@ -1333,7 +1336,7 @@ weston_wm_handle_event(int fd, uint32_t mask, void *data)
continue;
}
- switch (event->response_type & ~0x80) {
+ switch (EVENT_TYPE(event)) {
case XCB_BUTTON_PRESS:
case XCB_BUTTON_RELEASE:
weston_wm_handle_button(wm, event);
--
1.8.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/3] xwm: Check result of xcb_get_atom_name_reply
When printing debug information about atoms, the XWM would crash if the X
server failed to respond to a request about atom names. In practice this
occurred when the server itself crashed, e.g. when starting mplayer with the
"xv" vo.
---
src/xwayland/window-manager.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index a021c76..d4be4ca 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -137,9 +137,15 @@ get_atom_name(xcb_connection_t *c, xcb_atom_t atom)
cookie = xcb_get_atom_name (c, atom);
reply = xcb_get_atom_name_reply (c, cookie, &e);
- snprintf(buffer, sizeof buffer, "%.*s",
-xcb_get_atom_name_name_length (reply),
-xcb_get_atom_name_name (reply));
+
+ if(reply) {
+ snprintf(buffer, sizeof buffer, "%.*s",
+xcb_get_atom_name_name_length (reply),
+xcb_get_atom_name_name (reply));
+ } else {
+ snprintf(buffer, sizeof buffer, "(atom %u)", atom);
+ }
+
free(reply);
return buffer;
--
1.8.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 3/3] xwm: Don't set opaque region to cover window contents from X
Window contents cannot be assumed to be fully opaque for windows drawn with
a RGBA visual. Later the optimization of setting a full opaque region can
be reimplemented after checking that the windows involved aren't using RGBA
visuals.
The comment mentioning sampling of undefined alpha channel was irrelevant as
of f91871980e095caa827f4f39e6c178fc0a2bd396 and can safely be removed.
---
src/xwayland/window-manager.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index d4be4ca..68bc123 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -830,13 +830,8 @@ weston_wm_window_draw_decoration(void *data)
if (window->surface) {
pixman_region32_fini(&window->surface->pending.opaque);
- /* We leave an extra pixel around the X window area to
-* make sure we don't sample from the undefined alpha
-* channel when filtering. */
- pixman_region32_init_rect(&window->surface->pending.opaque,
- x - 1, y - 1,
- window->width + 2,
- window->height + 2);
+ pixman_region32_init(&window->surface->pending.opaque);
+ /* TODO: fill opaque region if client doesn't use 32-bit visual
*/
weston_surface_geometry_dirty(window->surface);
}
@@ -859,8 +854,8 @@ weston_wm_window_schedule_repaint(struct weston_wm_window
*window)
if (window->surface != NULL) {
weston_wm_window_get_frame_size(window, &width,
&height);
pixman_region32_fini(&window->surface->pending.opaque);
-
pixman_region32_init_rect(&window->surface->pending.opaque, 0, 0,
- width, height);
+ pixman_region32_init(&window->surface->pending.opaque);
+ /* TODO: fill opaque region if client doesn't use
32-bit visual */
weston_surface_geometry_dirty(window->surface);
}
return;
--
1.8.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] Handle SYN_DROPPED, filter keys with a bitmap
I feel like this unreliability can be passed on to the clients. Clients are probably going to be written to assume there may be bugs in the compositor and that events will get mangled. Even if the compositor is perfect, most toolkits can mangle events themselves (ie they skip events when no widget has focus, etc). Thus in the end the clients end up doing all this work themselves. Except they can be a good deal simpler if they are only interested in "are any buttons down" rather than which ones, which actually covers a lot of potential clients. Also moving code to the clients seems to be more Wayland-ish. So I would just send the press/release events exactly as the device reported them to the client. Clients can easily handle multiples in exactly the same way the compositor does, and they can do it at whatever layer in their own code that they want to be reliable. On SYN_REPORT I would send an event that says exactly how the buttons are right now. The compositor does have to know whether any buttons are held down because that determines whether device events are sent to the client that got the last down event or to the client that now has focus (I think this is called "passive grab", and is why you can push a button in a window, drag outside the window, and release, and that client knows you let go. Because of this the compositor should send this very important information, so we are guaranteed that the client and compositor agree on this, even if some press/release events were mangled or interpreted differently by them. This could be any of: 1. A flag on the release event saying there are now no buttons down 2. A special "there are no buttons down" event sent after release 3. Send the buttonmap event (with no buttons down) after release. Martin Minarik wrote: Since evdev keys are unreliable, they might randomly get dropped, such as, on SYN_DROPPED. Even SYN_DROPPED is sometimes not delivered. Clients, compositor are not able to recover from duplicate press/release. This fixes this bug, thereby making the compositor and clients useable even under critical system conditions such as, but not limited to, high system load, device malfunction. This improves reliability. Every device contains a key bitmap. Each passing key press/release is checked and recorded. Duplicated presses, releases are handled by emitting the opposite type event in between (the time is faked -1 time unit). This is a last resort solution and happens only very rarely. When a SYN_DROPPED is detected: 1 wait until after the next SYN_REPORT. 2 Ask the kernel for the actual state of buttons 3 Compare the buttons with the internal key bitmap, to see what changed. 4 Send each different key via notify to the compositor, with timestamp. 5 Update the internal key bitmap to match the kernel's Disadvantages of this approach Each evdev device consumes 96 bytes more memory. Table lookup+bit toggle for almost key. Don't know the timestamp of missing keys. The key_notify from kernel bitmap compare occurs later the real missing event. That's a timestamp issue. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
