xfwm4-wayland changes
Hi, Changes in my latest rewrite of xfwm4-wayland: The Wayland compositor now uses some of xfwm4's original code. As I have said before, the X11 and Wayland versions of the compositor are now in the same binary and the compositor now uses the wlr-scene API. I have now renamed my new wayland-2 branch to wayland and renamed my old wayland branch to wayland-old. My latest code can now be found here: https://github.com/adlocode/xfwm4/tree/wayland Regards adlo
Re: xfwm4-wayland: use wlr-scene API
Correction: the View struct is in src/wayland/output.h, not view.h > On 4 Apr 2023, at 08:07, adlo wrote: > > If I use my View struct (src/wayland/view.h), everything is fine. But if I > try to copy the contents of the View struct into the Client struct > (src/client.h) and use the Client struct to hold data about my view instead > of the View struct, so every instance of View is replaced with Client, my > compositor segfaults at src/wayland/xdg_shell.c line 170 when I close the > last window on the screen. (I think it was that line, I don't have the > backtrace to hand.) > > I did some experimentation and copied my entire View struct into client.h and > it still seemed to work. I think it also starts working if I make the Client > struct smaller. So I think maybe it's got something to do with the size of > the struct. > > What's going on? > > Regards > adlo > >> On 31 Mar 2023, at 12:44, adlo wrote: >> I have rewritten my Wayland port of xfwm4 for the third or fourth time. >> >> I kept adding thousands of lines of code and then scrapping it, so the >> commit history was getting full of scrapped code, so I decided to reset >> to master and start from scratch. >> >> I have created a new wayland-2 branch. At some point I may rename this >> branch to wayland and rename the old wayland branch to wayland-old or >> something. >> >> My compositor now uses the wlr-scene API, which handles a lot of the >> low-level stuff for you, such as rendering and damage tracking, which >> makes the code much simpler to write and more easily maintainable. >> >> I have now moved the Wayland compositor code into the original xfwm4 >> binary, so the Wayland compositor and X11 version are now in one >> binary. >> >> You can run the Wayland compositor with the command xfwm4 --wayland >> >> You can find the repo here: >> https://github.com/adlocode/xfwm4/tree/wayland-2 >> >> Regards >> adlo
Re: xfwm4-wayland: use wlr-scene API
If I use my View struct (src/wayland/view.h), everything is fine. But if I try to copy the contents of the View struct into the Client struct (src/client.h) and use the Client struct to hold data about my view instead of the View struct, so every instance of View is replaced with Client, my compositor segfaults at src/wayland/xdg_shell.c line 170 when I close the last window on the screen. (I think it was that line, I don't have the backtrace to hand.) I did some experimentation and copied my entire View struct into client.h and it still seemed to work. I think it also starts working if I make the Client struct smaller. So I think maybe it's got something to do with the size of the struct. What's going on? Regards adlo > On 31 Mar 2023, at 12:44, adlo wrote: > I have rewritten my Wayland port of xfwm4 for the third or fourth time. > > I kept adding thousands of lines of code and then scrapping it, so the > commit history was getting full of scrapped code, so I decided to reset > to master and start from scratch. > > I have created a new wayland-2 branch. At some point I may rename this > branch to wayland and rename the old wayland branch to wayland-old or > something. > > My compositor now uses the wlr-scene API, which handles a lot of the > low-level stuff for you, such as rendering and damage tracking, which > makes the code much simpler to write and more easily maintainable. > > I have now moved the Wayland compositor code into the original xfwm4 > binary, so the Wayland compositor and X11 version are now in one > binary. > > You can run the Wayland compositor with the command xfwm4 --wayland > > You can find the repo here: > https://github.com/adlocode/xfwm4/tree/wayland-2 > > Regards > adlo
xfwm4-wayland: use wlr-scene API
I have rewritten my Wayland port of xfwm4 for the third or fourth time. I kept adding thousands of lines of code and then scrapping it, so the commit history was getting full of scrapped code, so I decided to reset to master and start from scratch. I have created a new wayland-2 branch. At some point I may rename this branch to wayland and rename the old wayland branch to wayland-old or something. My compositor now uses the wlr-scene API, which handles a lot of the low-level stuff for you, such as rendering and damage tracking, which makes the code much simpler to write and more easily maintainable. I have now moved the Wayland compositor code into the original xfwm4 binary, so the Wayland compositor and X11 version are now in one binary. You can run the Wayland compositor with the command xfwm4 --wayland You can find the repo here: https://github.com/adlocode/xfwm4/tree/wayland-2 Regards adlo
Re: xfwm4-wayland: wlroots branch merged into wayland branch
> On 23 Dec 2022, at 15:56, Simon Zeni wrote: > > What stops you to do GTK on the server side? Do you need input from the user? > How can I do GTK on the server side? I didn't think it was possible because GTK needs to connect to a server. I think I investigated it and you ended up with either the GTK bit running, or the compositor, but not both. I know you can do cairo server-side, because that's just drawing pixels on the screen, but I didn't think you could do GTK. Regards adlo
Re: xfwm4-wayland: wlroots branch merged into wayland branch
My wayland port of xfwm4 currently consists of two binaries, a compositor and a helper client. The compositor sends events to the helper client using a private protocol. The helper client controls the compositor. The helper client basically contains all the code of the original xfwm4. The tabwin widget is rendered by the helper client. Essentially my Wayland compositor is behaving like an X server and my helper client acts like a traditional X11 window manager. The compositor-and-helper-client approach works fine for the tabwin, but it may have limitations when attempting to port server-side decorations. I suppose copying the X11 approach could result in a lot of pointless back-and-forth between the helper client and server. How could I port xfwm4's window decorations code to Wayland? Also, window thumbnails may be a very difficult problem. There isn't even an agreed way to do that on Wayland. Should the compositor render the thumbnails, or should it pass the window's buffer to a client? Or another way I haven't thought of? My compositor currently consists of two binaries. I suppose if I wanted to make it one binary, the GTK code would have to be removed as afaik you can't do GTK server side? I don't necessarily want to make it one binary. How does mutter manage to be one binary? On X11, the window manager is a client but on Wayland the window manager is a server, so the directionality of X11 and Wayland is the complete opposite. Regards adlo > On 16 Dec 2022, at 06:58, adlo wrote: > > The wlroots version of xfwm4-wayland now has partial support for the > wlr-foreign-toplevel protocol. > > I have now declared feature parity with the libweston version, so I > have merged the wlroots branch into the wayland branch. > > Link to the git repository: > https://github.com/adlocode/xfwm4/tree/wayland > > Regards > adlo
xfwm4-wayland: wlroots branch merged into wayland branch
The wlroots version of xfwm4-wayland now has partial support for the wlr-foreign-toplevel protocol. I have now declared feature parity with the libweston version, so I have merged the wlroots branch into the wayland branch. Link to the git repository: https://github.com/adlocode/xfwm4/tree/wayland Regards adlo
xfwm4-wayland changes
Here are the latest changes for xfwm4-wayland: - Merge patch to fix SSD windows displaying as empty frames - Merge patch to fix crash when opening window with no title - Rename compositor binary to xfwm4-wayland - Fix crash when using pixman renderer - Merge the original X11 version of xfwm4 and the shell helper client for the Wayland version (xfwm4-wayland-shell) into the same binary. This binary is now called "xfwm4". This should mean that the original X11 version of xfwm4 has now been ported to the meson build system. I haven't tested it on X11 though. - Keyboard shortcuts are now kinda configurable? Though it currently only works for the alt-tab switcher, and the only modifier key it recognises is Alt. Git repository: https://github.com/adlocode/xfwm4/tree/wlroots Regards adlo
Re: xkbcommon: Converting keysym to keycode
afaict there’s a for loop that iterates over all the layouts, and within that it iterates over all the shift levels, and within that it iterates over all the modifier masks? Is that what’s going on? So basically it’s iterating over them until it finds a match? In that printf on line 220, would the value of “keycode” at that point be the best approximation of XKeysymToKeycode ()? What’s the difference between shift level and modifier state? They seem to overlap somewhat. Is it that the Shift key can be both a modifier and a shift level, but the Num Lock key is a shift level but not a modifier? Regards adlo > On 5 Dec 2021, at 23:14, adlo wrote: > > >> >> On 5 Dec 2021, at 05:15, Peter Hutterer wrote: >> >> please look at the source, it's not a huge program. > > I have looked at the source, it’s just that I can’t see anything that’s > directly related to what I’m trying to do. It calls > xkb_keymap_key_get_mods_for_level(), which seems to be related to getting the > mods, and it seems to have things that get the name of a key, or get a key > from the name, but I can’t see anything that looks like it’s related to > getting or approximating a keycode from a keysym. >
Fwd: xfway: added support for alt-tab switcher
Begin forwarded message: > From: adlo > Date: 17 July 2022 at 02:54:11 BST > To: Xfce development list > Subject: Re: xfway: added support for alt-tab switcher > > >> >> On 15 Jan 2022, at 14:02, Alex wrote: >> >> Hi adlo, >> >> Interesting ! What are your further plans with it ? >> >> You plan to dump the remaining X11 code ? Or do you plan to support >> both, X11 and wayland sessions ? > > I think I plan to support both X11 and Wayland, though I haven’t actually > tested that the X11 code still works. > >> You want to rename the project to xfway ? (keeping "xfwm4" as name would >> be confusing if it is going to be a wayland-only compositor) > > I’m not sure if I want it to be an independent project or an actual port of > xfwm4 to Wayland that’s officially part of xfce, so if it’s an independent > project it will be called xfway and if it’s an official part of xfce it would > be called xfwm4. > > ofourdan favours the libmutter route. The advantage is that it would be a > familiar ecosystem, as there is already a good relationship between the xfce > and GNOME communities. However, this would mean that xfce4-panel and > xfdesktop would have to be integrated into the compositor and they would no > longer be separate components. > > I keep wondering whether it would be better to use libmutter, but I don’t > think I would be interested in developing a highly integrated desktop > environment. > > As a result of being unsure which library I should use, I’m not sure whether > I want this to be an official part of Xfce or an independent project. > > > Regards > adlo
Re: xfwm4-wayland (xfway) is being ported to wlroots
I have two repos, xfwm4 and xfway. The xfway repo is now extremely outdated and I’m not sure what to do. I could copy the xfwm4 repo over to the xfway repo, but the histories are completely different. I might end up having to completely rewrite the history of the xfway repo. Also I might want the two repos to diverge in some ways but still keep up with the changes from the other one. I ended up with two repos because I’m not sure if I want this to be an independent project or an official part of Xfce. Regards adlo > On 16 Jul 2022, at 00:01, Alex wrote: > > Hi Adlo, > > great to hear so, sounds promising ! > > I have currently trouble to build it (sent you a pm). When the build > runs fine for me, I'll give it a spin. > > When you succeed in bringing the project into a good shape, and after > some testing, I suppose it would make sense to host it on > https://gitlab.xfce.org/ (if non of the core devs puts a veto) > > Cheers, Alex > >> Am 15.07.22 um 06:54 schrieb adlo: >> I am currently porting xfwm4-wayland (xfway) to wlroots. It is based on >> Ariadne's Hopalong compositor. >> >> I have also ported xfwm4's build system to Meson. >> >> At the moment there are feature regressions compared to the libweston >> version. >> >> You can build it with meson. >> >> https://github.com/adlocode/xfwm4/tree/wlroots >> >> Regards >> >> adlo >> ___ >> Xfce4-dev mailing list >> xfce4-...@xfce.org >> https://mail.xfce.org/mailman/listinfo/xfce4-dev > > > ___ > Xfce4-dev mailing list > xfce4-...@xfce.org > https://mail.xfce.org/mailman/listinfo/xfce4-dev
xfwm4-wayland (xfway) is being ported to wlroots
I am currently porting xfwm4-wayland (xfway) to wlroots. It is based on Ariadne's Hopalong compositor. I have also ported xfwm4's build system to Meson. At the moment there are feature regressions compared to the libweston version. You can build it with meson. https://github.com/adlocode/xfwm4/tree/wlroots Regards adlo
Re: xfway: added support for alt-tab switcher
xfway is a Wayland compositor inspired by xfwm4. xfway is now able to run xfwm4’s alt-tab window switcher code. The current developments are at the adlocode/xfwm4 repo, the xfway repo is currently outdated. Regards adlo > On 14 Jan 2022, at 03:27, adlo wrote: > > xfway now supports the alt-tab switcher: > > https://github.com/adlocode/xfwm4/tree/wayland > > Regards > > adlo
xfway: added support for alt-tab switcher
xfway now supports the alt-tab switcher: https://github.com/adlocode/xfwm4/tree/wayland Regards adlo
labwc backport to wlroots 0.14
Hi I’ve backported labwc to wlroots 0.14: https://github.com/adlocode/labwc/tree/wlroots-0.14-backports It might be useful when developing compositors for non-bleeding-edge distros, perhaps. Regards adlo
Re: xkbcommon: Converting keysym to keycode
> On 5 Dec 2021, at 05:15, Peter Hutterer wrote: > > please look at the source, it's not a huge program. I have looked at the source, it’s just that I can’t see anything that’s directly related to what I’m trying to do. It calls xkb_keymap_key_get_mods_for_level(), which seems to be related to getting the mods, and it seems to have things that get the name of a key, or get a key from the name, but I can’t see anything that looks like it’s related to getting or approximating a keycode from a keysym.
Re: xkbcommon: Converting keysym to keycode
Does xkbcommon have modifier masks, like that used in the “state” field of XKeyEvent? > On 4 Dec 2021, at 08:34, adlo wrote: > > Basically the program I’m working on was originally designed for X11, and > I’m trying to adapt it to Wayland. I’m trying to find an equivalent to > XKeysymToKeycode(). > >> it doesn't, but if you look at xkbcli how-to-type and it's source >> (tools/how-to-type.c) that's the closest approximation. > > What does this program do? Does it iterate through all possible keycodes and > lookup the keysym for them? >> >> Main reason is that the keycode->keysym conversion is one-way only and it's >> not 100% reliable to go back. e.g. if a modifier is locked/latched you cannot >> access certain keysyms without unlocking that modifier, etc. > > How would I deal with capital letters with regards to getting a keycode from > a keysym? > >> KEY_TAB is defined in linux/input-event-codes.h. XKB uses those keycodes + 8 >> for the evdev ruleset (see /usr/share/X11/xkb/keycodes/evdev for the mapping) >> and it goes from there. If you're using a different ruleset you're going to >> get interesting results but evdev is effectively hardcoded everywhere anyway, >> so you won't. > > Is linux/input-event-codes.h keycodes or keysyms?
Re: xkbcommon: Converting keysym to keycode
Basically the program I’m working on was originally designed for X11, and I’m trying to adapt it to Wayland. I’m trying to find an equivalent to XKeysymToKeycode(). > it doesn't, but if you look at xkbcli how-to-type and it's source > (tools/how-to-type.c) that's the closest approximation. What does this program do? Does it iterate through all possible keycodes and lookup the keysym for them? > > Main reason is that the keycode->keysym conversion is one-way only and it's > not 100% reliable to go back. e.g. if a modifier is locked/latched you cannot > access certain keysyms without unlocking that modifier, etc. How would I deal with capital letters with regards to getting a keycode from a keysym? > KEY_TAB is defined in linux/input-event-codes.h. XKB uses those keycodes + 8 > for the evdev ruleset (see /usr/share/X11/xkb/keycodes/evdev for the mapping) > and it goes from there. If you're using a different ruleset you're going to > get interesting results but evdev is effectively hardcoded everywhere anyway, > so you won't. Is linux/input-event-codes.h keycodes or keysyms?
xkbcommon: Converting keysym to keycode
Hi Does xkbcommon have a function to convert a keysym to a keycode? Also, what keycodes does Weston use? It seems that in libweston, KEY_TAB is assigned the number 15. Is this a real keycode? Is this a standard keycode? Is it used in xkbcommon or anything like that? Regards adlo
Binding to all key events in libweston-desktop
Is it possible to have a callback function for *all* key events using weston_compositor_add_key_binding () in libweston-desktop? Are the modifiers passed to the callback function, or only the keycode? Regards adlo
Re: xfway: a Wayland compositor inspired by xfwm4
I'd just like to clarify that xfway is highly experimental. It's basically just an idea at this point. I have no idea if it will actually go anywhere. For the foreseeable future, there will be no Xfce on Wayland. It's entirely possible that my design goals are different from that of Xfce, and I would be best served by doing my own thing separate from Xfce. Regards adlo > On 27 Jun 2019, at 19:30, adlo wrote: > > xfway is a Wayland compositor inspired by xfwm4: > > https://github.com/adlocode/xfway > > I'm not sure if this is an actual attempt at a port or more of a spin-off > project a la Sway, but here it is, and I just wondered if you would like to > have a look at it. > > It supports the wlr-foreign-toplevel protocol, which can be used for window > management functions, and the wlr-layer-shell protocol, which can be used for > creating panels etc. > > At the moment it's little more than a Weston clone with some wlroots support, > but there you go. > > What do you think? > > Regards > > adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
xfway: a Wayland compositor inspired by xfwm4
xfway is a Wayland compositor inspired by xfwm4: https://github.com/adlocode/xfway I'm not sure if this is an actual attempt at a port or more of a spin-off project a la Sway, but here it is, and I just wondered if you would like to have a look at it. It supports the wlr-foreign-toplevel protocol, which can be used for window management functions, and the wlr-layer-shell protocol, which can be used for creating panels etc. At the moment it's little more than a Weston clone with some wlroots support, but there you go. What do you think? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Rendering window thumbnails etc
> On 22 May 2019, at 21:36, Ilia Bozhinov wrote: > > If you have a panel/any UI elements, then you most probably have a protocol > to communicate that the UI element surface is a special surface. You could > then just extend this protocol so that you specify Z-ordering of these > surfaces, and then the compositor should respect that. > > If it might help here is the wlr-layer-shell protocol: > https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-layer-shell-unstable-v1.xml > > With it, you basically have several layers where you can put the UI elements > that you have drawn outside of the compositor, and then you can use the > `namespace` to adjust ordering within the specific layer. > I am attempting to implement wlr-layer-shell on a libweston-based compositor. What would be the equivalent of wlr_surface_has_buffer () for a weston_surface? In the get_popup function, what could I use instead of wlr_xdg_surface and wlr_xdg_popup? Regards adlo___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Rendering window thumbnails etc
> On 22 May 2019, at 21:36, Ilia Bozhinov wrote: > > If you have a panel/any UI elements, then you most probably have a protocol > to communicate that the UI element surface is a special surface. You could > then just extend this protocol so that you specify Z-ordering of these > surfaces, and then the compositor should respect that. > With such a protocol, how would I create a window using GTK and then tell the compositor that it's a special surface? Client-side, I may have access to the GtkWindow's wl_surface, I think, whereas server-side I have objects such as weston_surface, weston_desktop_surface. How are these two connected? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
> On 1 May 2019, at 10:34, Pekka Paalanen wrote: > > it is all just the normal Wayland protocol exchange but with a new > interface of your own design. I'm not sure if there is a really > minimal example, but I'll list at least some. > > One example of such private protocol extension is > https://gitlab.freedesktop.org/wayland/weston/blob/master/protocol/weston-desktop-shell.xml > > The server-side implementation of it is in shell.c and the > entrypoint to that is > https://gitlab.freedesktop.org/wayland/weston/blob/master/desktop-shell/shell.c#L5143 > >wl_global_create(ec->wl_display, > _desktop_shell_interface, 1, > shell, bind_desktop_shell) > > which installs the protocol extension in the compositor. You can > see everything about the implementation by following all callbacks > that get registered, starting with bind_desktop_shell(). > > The privacy of the protocol extension, the installed wayland global > really, is achieved in > https://gitlab.freedesktop.org/wayland/weston/blob/master/desktop-shell/shell.c#L4366 > >shell->child.client = weston_client_start(shell->compositor, > shell->client); > > which creates the Wayland connection before forking the child > process and bind_desktop_shell() then verifying the client trying > to bind to the global is the client that was forked. > Is it required that the helper client be a separate binary that must be launched through a path? Is it possible for the client to just be a function in my main program? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
> On 1 May 2019, at 10:34, Pekka Paalanen wrote:
>
> On Wed, 1 May 2019 03:24:04 +0100
> adlo wrote:
>
> it is all just the normal Wayland protocol exchange but with a new
> interface of your own design. I'm not sure if there is a really
> minimal example, but I'll list at least some.
>
> One example of such private protocol extension is
> https://gitlab.freedesktop.org/wayland/weston/blob/master/protocol/weston-desktop-shell.xml
>
> The server-side implementation of it is in shell.c and the
> entrypoint to that is
> https://gitlab.freedesktop.org/wayland/weston/blob/master/desktop-shell/shell.c#L5143
>
>wl_global_create(ec->wl_display,
> _desktop_shell_interface, 1,
> shell, bind_desktop_shell)
>
> which installs the protocol extension in the compositor. You can
> see everything about the implementation by following all callbacks
> that get registered, starting with bind_desktop_shell().
>
> The privacy of the protocol extension, the installed wayland global
> really, is achieved in
> https://gitlab.freedesktop.org/wayland/weston/blob/master/desktop-shell/shell.c#L4366
>
>shell->child.client = weston_client_start(shell->compositor,
> shell->client);
>
> which creates the Wayland connection before forking the child
> process and bind_desktop_shell() then verifying the client trying
> to bind to the global is the client that was forked.
>
>
> The client-side implementation is in desktop-shell.c with the entry
> point at
> https://gitlab.freedesktop.org/wayland/weston/blob/master/clients/desktop-shell.c#L1392
>
>if (!strcmp(interface, "weston_desktop_shell")) {
>desktop->shell = display_bind(desktop->display,
> id,
> _desktop_shell_interface,
> 1);
>weston_desktop_shell_add_listener(desktop->shell,
> ,
> desktop);
>
How do I ensure my client will still launch no matter what directory I run my
compositor from? How do I get the absolute path of my client?
Also, how do I ensure it will still launch correctly no matter whether I am
running it from the builddir or the installdir? The locally built version
should launch the locally built client and the installed version should launch
the installed client.
Regards
adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor crashes when switching tty
On Fri, 2019-05-31 at 01:22 +0100, adlo wrote: > On Thu, 2019-05-30 at 13:39 +0300, Pekka Paalanen wrote: > > > > Hi, > > > > as always, look at the very first problem reported. Other problems > > may be fallout from the first one, so fix the first one, and > > repeat. > > > > It is quite easy to corrupt a list based on struct wl_list, which > > will then result in more errors all over the place. > > > > The first problem is this: > > ==13998== Invalid write of size 8 > ==13998==at 0x4884ADB: wl_list_remove (in /usr/lib64/libwayland- > server.so.0.1.0) > ==13998==by 0x48A2585: weston_view_set_output (in > /usr/lib64/libweston-6.so.0.0.0) > ==13998==by 0x48A41AD: weston_view_unmap (in > /usr/lib64/libweston- > 6.so.0.0.0) > ==13998==by 0x48A5587: weston_view_destroy (in > /usr/lib64/libweston-6.so.0.0.0) > ==13998==by 0x48A5664: weston_surface_destroy (in > /usr/lib64/libweston-6.so.0.0.0) > ==13998==by 0x4880927: ??? (in /usr/lib64/libwayland- > server.so.0.1.0) > ==13998==by 0x4884A7F: ??? (in /usr/lib64/libwayland- > server.so.0.1.0) > ==13998==by 0x4884FC3: ??? (in /usr/lib64/libwayland- > server.so.0.1.0) > ==13998==by 0x4880AA1: wl_client_destroy (in > /usr/lib64/libwayland- > server.so.0.1.0) > ==13998==by 0x4880EDD: wl_display_flush_clients (in > /usr/lib64/libwayland-server.so.0.1.0) > ==13998==by 0x4880F17: wl_display_run (in /usr/lib64/libwayland- > server.so.0.1.0) > ==13998==by 0x403A57: main (main-wayland.c:625) > ==13998== Address 0x9fcda10 is 96 bytes inside a block of size 120 > free'd > ==13998==at 0x4839A0C: free (vg_replace_malloc.c:540) > ==13998==by 0x48DD073: ??? (in /usr/lib64/libweston-desktop- > 6.so.0.0.0) > ==13998==by 0x48D8E53: ??? (in /usr/lib64/libweston-desktop- > 6.so.0.0.0) > ==13998==by 0x4880927: ??? (in /usr/lib64/libwayland- > server.so.0.1.0) > ==13998==by 0x4880993: wl_resource_destroy (in > /usr/lib64/libwayland-server.so.0.1.0) > ==13998==by 0x5984B27: ffi_call_unix64 (in > /usr/lib64/libffi.so.6.0.2) > ==13998==by 0x5984338: ffi_call (in /usr/lib64/libffi.so.6.0.2) > ==13998==by 0x48841B6: ??? (in /usr/lib64/libwayland- > server.so.0.1.0) > ==13998==by 0x4880D31: ??? (in /usr/lib64/libwayland- > server.so.0.1.0) > ==13998==by 0x4882369: wl_event_loop_dispatch (in > /usr/lib64/libwayland-server.so.0.1.0) > ==13998==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland- > server.so.0.1.0) > ==13998==by 0x403A57: main (main-wayland.c:625) > > However, this doesn't seem to call back into my compositor's code at > any point. I see a call to weston_surface_destroy (), which suggests > a > surface was destroyed. However, if a surface was destroyed, I would > expect to see a call to surface_removed () in src/shell.c. How do I > interpret this? > How do I debug something that isn't even part of my code? It goes straight from main to wl_display_run to library code without calling any of my callbacks. Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor crashes when switching tty
On Thu, 2019-05-30 at 13:39 +0300, Pekka Paalanen wrote:
> On Thu, 30 May 2019 00:50:32 +0100
> adlo wrote:
>
> > Also, there are lots of "Invalid writes of size 8", but a lot of
> > them
> > don't seem to originate from functions in my program, but from the
> > Wayland libraries themselves. What is going on there?
>
> Hi,
>
> as always, look at the very first problem reported. Other problems
> may be fallout from the first one, so fix the first one, and repeat.
>
> It is quite easy to corrupt a list based on struct wl_list, which
> will then result in more errors all over the place.
>
The first problem is this:
==13998== Invalid write of size 8
==13998==at 0x4884ADB: wl_list_remove (in /usr/lib64/libwayland-
server.so.0.1.0)
==13998==by 0x48A2585: weston_view_set_output (in
/usr/lib64/libweston-6.so.0.0.0)
==13998==by 0x48A41AD: weston_view_unmap (in /usr/lib64/libweston-
6.so.0.0.0)
==13998==by 0x48A5587: weston_view_destroy (in
/usr/lib64/libweston-6.so.0.0.0)
==13998==by 0x48A5664: weston_surface_destroy (in
/usr/lib64/libweston-6.so.0.0.0)
==13998==by 0x4880927: ??? (in /usr/lib64/libwayland-
server.so.0.1.0)
==13998==by 0x4884A7F: ??? (in /usr/lib64/libwayland-
server.so.0.1.0)
==13998==by 0x4884FC3: ??? (in /usr/lib64/libwayland-
server.so.0.1.0)
==13998==by 0x4880AA1: wl_client_destroy (in /usr/lib64/libwayland-
server.so.0.1.0)
==13998==by 0x4880EDD: wl_display_flush_clients (in
/usr/lib64/libwayland-server.so.0.1.0)
==13998==by 0x4880F17: wl_display_run (in /usr/lib64/libwayland-
server.so.0.1.0)
==13998==by 0x403A57: main (main-wayland.c:625)
==13998== Address 0x9fcda10 is 96 bytes inside a block of size 120
free'd
==13998==at 0x4839A0C: free (vg_replace_malloc.c:540)
==13998==by 0x48DD073: ??? (in /usr/lib64/libweston-desktop-
6.so.0.0.0)
==13998==by 0x48D8E53: ??? (in /usr/lib64/libweston-desktop-
6.so.0.0.0)
==13998==by 0x4880927: ??? (in /usr/lib64/libwayland-
server.so.0.1.0)
==13998==by 0x4880993: wl_resource_destroy (in
/usr/lib64/libwayland-server.so.0.1.0)
==13998==by 0x5984B27: ffi_call_unix64 (in
/usr/lib64/libffi.so.6.0.2)
==13998==by 0x5984338: ffi_call (in /usr/lib64/libffi.so.6.0.2)
==13998==by 0x48841B6: ??? (in /usr/lib64/libwayland-
server.so.0.1.0)
==13998==by 0x4880D31: ??? (in /usr/lib64/libwayland-
server.so.0.1.0)
==13998==by 0x4882369: wl_event_loop_dispatch (in
/usr/lib64/libwayland-server.so.0.1.0)
==13998==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland-
server.so.0.1.0)
==13998==by 0x403A57: main (main-wayland.c:625)
However, this doesn't seem to call back into my compositor's code at
any point. I see a call to weston_surface_destroy (), which suggests a
surface was destroyed. However, if a surface was destroyed, I would
expect to see a call to surface_removed () in src/shell.c. How do I
interpret this?
Trying a different tack, it seems that the errors disappear if I remove
the call to free () in surface_removed ():
void surface_removed (struct weston_desktop_surface *desktop_surface,
void *user_data)
{
DisplayInfo *server = user_data;
CWindowWayland *self = weston_desktop_surface_get_user_data
(desktop_surface);
if (!self)
return;
wl_signal_emit (>destroy_signal, self);
weston_desktop_surface_unlink_view (self->view);
weston_view_destroy (self->view);
weston_desktop_surface_set_user_data (desktop_surface, NULL);
free (self); //errors go away if I remove this
}
How can I fix this?
Regards
adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor crashes when switching tty
On Wed, 2019-05-29 at 08:19 -0500, Matteo Valdina wrote: > Re-iterate the process.Run valgrind, read the log, search for bugs. > Until valgrind run smoothly. > > Best > > On Wed, May 29, 2019, 02:32 adlo wrote: > > On 29 May 2019, at 03:53, Matteo Valdina > > wrote: > > > > > As valgrind pointing out at shell.c line 982 > > > > > > > > > > > > > > > shell = zalloc (sizeof (shell)); > > > > > > Here you are allocating the pointer size not the structure size. > > > You probably want type Shell. > > > > > > > This reduces the amount of crashing, but does not completely > > eliminate it. My compositor still coredumps when switching vt > > multiple times, especially when also opening and closing windows on > > my compositor. > > Here is the valgrind output: ==13998== Memcheck, a memory error detector ==13998== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==13998== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==13998== Command: src/xfway ==13998== Parent PID: 11262 ==13998== ==13998== Warning: noted but unhandled ioctl 0x6458 with no size/direction hints. ==13998==This could cause spurious value errors to appear. ==13998==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==13998== Invalid write of size 8 ==13998==at 0x4884ADB: wl_list_remove (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x48A2585: weston_view_set_output (in /usr/lib64/libweston-6.so.0.0.0) ==13998==by 0x48A41AD: weston_view_unmap (in /usr/lib64/libweston- 6.so.0.0.0) ==13998==by 0x48A5587: weston_view_destroy (in /usr/lib64/libweston-6.so.0.0.0) ==13998==by 0x48A5664: weston_surface_destroy (in /usr/lib64/libweston-6.so.0.0.0) ==13998==by 0x4880927: ??? (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x4884A7F: ??? (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x4884FC3: ??? (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x4880AA1: wl_client_destroy (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x4880EDD: wl_display_flush_clients (in /usr/lib64/libwayland-server.so.0.1.0) ==13998==by 0x4880F17: wl_display_run (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x403A57: main (main-wayland.c:625) ==13998== Address 0x9fcda10 is 96 bytes inside a block of size 120 free'd ==13998==at 0x4839A0C: free (vg_replace_malloc.c:540) ==13998==by 0x48DD073: ??? (in /usr/lib64/libweston-desktop- 6.so.0.0.0) ==13998==by 0x48D8E53: ??? (in /usr/lib64/libweston-desktop- 6.so.0.0.0) ==13998==by 0x4880927: ??? (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x4880993: wl_resource_destroy (in /usr/lib64/libwayland-server.so.0.1.0) ==13998==by 0x5984B27: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==13998==by 0x5984338: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==13998==by 0x48841B6: ??? (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x4880D31: ??? (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x4882369: wl_event_loop_dispatch (in /usr/lib64/libwayland-server.so.0.1.0) ==13998==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x403A57: main (main-wayland.c:625) ==13998== Block was alloc'd at ==13998==at 0x483AB1A: calloc (vg_replace_malloc.c:762) ==13998==by 0x40447E: surface_added (shell.c:255) ==13998==by 0x48D81EB: ??? (in /usr/lib64/libweston-desktop- 6.so.0.0.0) ==13998==by 0x48DCBF0: ??? (in /usr/lib64/libweston-desktop- 6.so.0.0.0) ==13998==by 0x48DCDCE: ??? (in /usr/lib64/libweston-desktop- 6.so.0.0.0) ==13998==by 0x5984B27: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==13998==by 0x5984338: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==13998==by 0x48841B6: ??? (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x4880D31: ??? (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x4882369: wl_event_loop_dispatch (in /usr/lib64/libwayland-server.so.0.1.0) ==13998==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x403A57: main (main-wayland.c:625) ==13998== ==13998== Invalid read of size 8 ==13998==at 0x4884AB4: wl_list_insert (in /usr/lib64/libwayland- server.so.0.1.0) ==13998==by 0x485F6AF: ??? (in /usr/lib64/libweston-6/drm- backend.so) ==13998==by 0x485E61C: ??? (in /usr/lib64/libweston-6/drm- backend.so) ==13998==by 0x485E77B: ??? (in /usr/lib64/libweston-6/drm- backend.so) ==13998==by 0x4863A45: ??? (in /usr/lib64/libweston-6/drm- backend.so) ==13998==by 0x636D6BC: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.19.10) ==13998==by 0x486291B: ??? (in /usr/lib64/libweston-6/drm- backend.so) ==13998==by 0x48823E8: wl_event_loop_dispatch (in
Re: Compositor crashes when switching tty
> On 29 May 2019, at 03:53, Matteo Valdina wrote: > > > As valgrind pointing out at shell.c line 982 > > shell = zalloc (sizeof (shell)); > > Here you are allocating the pointer size not the structure size. You probably > want type Shell. > This reduces the amount of crashing, but does not completely eliminate it. My compositor still coredumps when switching vt multiple times, especially when also opening and closing windows on my compositor. What else might I need to do? Is this code enough to open a basic display on the DRM backend? https://github.com/adlocode/xfway/blob/9a676ddd9eecc7f8e23915d5c79f57c6368d6fc7/src/main-wayland.c#L276 Regards adlo___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor crashes when switching tty
On Tue, 2019-05-28 at 13:38 -0400, Adam Jackson wrote: > On Tue, 2019-05-28 at 08:26 +0100, adlo wrote: > > When switching tty, my compositor crashes with error messages such > > as > > > > free (): invalid size Aborted (core dumped) > > or > > malloc (): invalid chunk size > > This means something is corrupting the malloc arena metadata. Run > your > compositor under valgrind and fix what it complains about. > Here is the valgrind output: ==15641== Memcheck, a memory error detector ==15641== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==15641== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==15641== Command: src/xfway ==15641== Parent PID: 7074 ==15641== ==15641== Invalid write of size 8 ==15641==at 0x404604: launch_desktop_shell_process (shell.c:961) ==15641==by 0x48822D2: wl_event_loop_dispatch_idle (in /usr/lib64/libwayland-server.so.0.1.0) ==15641==by 0x4882327: wl_event_loop_dispatch (in /usr/lib64/libwayland-server.so.0.1.0) ==15641==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland- server.so.0.1.0) ==15641==by 0x403A47: main (main-wayland.c:626) ==15641== Address 0x8f21c58 is 0 bytes after a block of size 8 alloc'd ==15641==at 0x483AB1A: calloc (vg_replace_malloc.c:762) ==15641==by 0x4052C2: zalloc (zalloc.h:38) ==15641==by 0x4052C2: xfway_server_shell_init (shell.c:982) ==15641==by 0x403A37: main (main-wayland.c:623) ==15641== ==15641== Invalid write of size 8 ==15641==at 0x40460D: launch_desktop_shell_process (shell.c:968) ==15641==by 0x48822D2: wl_event_loop_dispatch_idle (in /usr/lib64/libwayland-server.so.0.1.0) ==15641==by 0x4882327: wl_event_loop_dispatch (in /usr/lib64/libwayland-server.so.0.1.0) ==15641==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland- server.so.0.1.0) ==15641==by 0x403A47: main (main-wayland.c:626) ==15641== Address 0x8f21c78 is 24 bytes after a block of size 16 in arena "client" ==15641== ==15641== Invalid write of size 8 ==15641==at 0x4884AB8: wl_list_insert (in /usr/lib64/libwayland- server.so.0.1.0) ==15641==by 0x48822D2: wl_event_loop_dispatch_idle (in /usr/lib64/libwayland-server.so.0.1.0) ==15641==by 0x4882327: wl_event_loop_dispatch (in /usr/lib64/libwayland-server.so.0.1.0) ==15641==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland- server.so.0.1.0) ==15641==by 0x403A47: main (main-wayland.c:626) ==15641== Address 0x8f21c68 is 16 bytes after a block of size 8 alloc'd ==15641==at 0x483AB1A: calloc (vg_replace_malloc.c:762) ==15641==by 0x4052C2: zalloc (zalloc.h:38) ==15641==by 0x4052C2: xfway_server_shell_init (shell.c:982) ==15641==by 0x403A37: main (main-wayland.c:623) ==15641== valgrind: m_mallocfree.c:305 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. valgrind: Heap block lo/hi size mismatch: lo = 80, hi = 4211536. This is probably caused by your program erroneously writing past the end of a heap block and corrupting heap metadata. If you fix any invalid writes reported by Memcheck, this assertion failure will probably go away. Please try that before reporting this as a bug. host stacktrace: ==15641==at 0x58046F6A: ??? (in /usr/libexec/valgrind/memcheck- amd64-linux) ==15641==by 0x58047097: ??? (in /usr/libexec/valgrind/memcheck- amd64-linux) ==15641==by 0x5804723B: ??? (in /usr/libexec/valgrind/memcheck- amd64-linux) ==15641==by 0x580513A3: ??? (in /usr/libexec/valgrind/memcheck- amd64-linux) ==15641==by 0x5803DD8A: ??? (in /usr/libexec/valgrind/memcheck- amd64-linux) ==15641==by 0x5803CC8F: ??? (in /usr/libexec/valgrind/memcheck- amd64-linux) ==15641==by 0x58041E04: ??? (in /usr/libexec/valgrind/memcheck- amd64-linux) ==15641==by 0x5803C0C8: ??? (in /usr/libexec/valgrind/memcheck- amd64-linux) ==15641==by 0x1002D09984: ??? ==15641==by 0x1002BA5F2F: ??? ==15641==by 0x1002BA5F17: ??? ==15641==by 0x1002BA5F2F: ??? ==15641==by 0x1002BA5F3F: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 15641) ==15641==at 0x4884ABB: wl_list_insert (in /usr/lib64/libwayland- server.so.0.1.0) ==15641==by 0x48822D2: wl_event_loop_dispatch_idle (in /usr/lib64/libwayland-server.so.0.1.0) ==15641==by 0x4882327: wl_event_loop_dispatch (in /usr/lib64/libwayland-server.so.0.1.0) ==15641==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland- server.so.0.1.0) ==15641==by 0x403A47: main (main-wayland.c:626) client stack range: [0x1FFEFF5000 0x1FFF000FFF] client SP: 0x1FFEFFF6C8 valgrind stack range: [0x1002AA6000 0x1002BA5FFF] top usage: 8360 of 1048576 Thread 2: status = VgTs_WaitSys syscall 202 (lwpid 15659) ==15641==at 0x57A54E5: pthread_cond_wait@@GLIBC_2.3.2 (in /usr/lib64/libpthread-2.29.so) ==15641==by 0x6ECC5DA: ??? (in /usr/lib64/dri/i965_dri.so) ==15641==by 0x6ECC31A: ??? (in /usr/lib64/dri/i965_dri.so) ==15641==by 0x5
Compositor crashes when switching tty
When switching tty, my compositor crashes with error messages such as free (): invalid size Aborted (core dumped) or malloc (): invalid chunk size when running on the DRM backend. Here is my code: https://github.com/adlocode/xfway/blob/master/src/main-wayland.c https://github.com/adlocode/xfway/blob/master/src/main-wayland.c#L276 Interestingly, this issue first seemed to present itself in the last few commits when I added my desktop shell client, but as I think this still happens when removing this code, somehow I'm not sure that that actually caused it: https://github.com/adlocode/xfway/blob/master/src/shell.c#L989 How can I resolve this issue? Regards adlo___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: (No Subject)
> On 25 May 2019, at 14:44, Simon Ser wrote: > > Hi, > >> On Saturday, May 25, 2019 4:23 PM, Alexandre Mazari wrote: >> Greetings wayland-devel, >> >> I am currently looking at ways to abstract Xisms in Plasma >> global-menu daemon and applet and provide a Wayland implementation. >> >> X11/xcb is currently used there to set and obtain to/from the >> *active* window some metadata (atoms) relative to the DBus address of >> the application menu provider. >> >> A wayland implementation [0] should first be able to track the active >> window. >> AFAIK, none of the current protocols provides such mechanism. >> I wonder whether that is by design to avoid some info leakage or >> would an activeSurface/activeWindow method/signal couple make sense >> in xdg-shell or xdg_surface? > > Yes, this is by design. Regular clients don't have any way to list > other clients' toplevels or to manage them, unlike on X11. > > I don't think it would make sense to add such a request/event to > xdg-shell, because this is out-of-scope for xdg-shell. > >> Moreover, the shell compositor often has the best knowledge of the >> link between surface/window and their owner application. Specific >> clients (like the global-menu) might be interested in this data, >> avoiding convoluted ways to do the matching. a get_app_id request in >> xdg shell could prove useful there. >> >> What do you think? > > Some projects like GNOME make the compositor responsible for drawing > desktop UI elements like a global menu. This has the upside of being > easy to implement, but has also some downsides: for instance the > compositor is responsible for drawing complex UI elements, which slows > down composition and makes it more likely to crash. > > If you cannot or don't want to do it this way, other compositors > (e.g. Weston, KDE as far as I've understood, and many wlroots > compositors) typically use a dedicated protocol for privileged clients. > In the case of KWin, the existing KDE-specific Wayland protocols are > here: > https://github.com/KDE/kwayland/tree/master/src/client/protocols > > It's worth noting that as of now, only Weston restricts access to > privileged protocols to a limited set of clients. In other compositors, > these protocols are exposed to all clients (and this has security > implications). > > Regarding this specific use-case, wlroots has standardized a protocol > for listing and managing toplevels: > https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml > Are there any examples of server-side implementations of plasma-window-management.xml on libweston? Alternatively, are there any plain C implementations of the same without all the KDE/Qt stuff? What would a basic boilerplate implementation of plasma-window-management look like on libweston? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Rendering window thumbnails etc
> On 24 May 2017, at 19:41, Quentin Glidic
> wrote:
>
> On 5/24/17 8:37 PM, adlo wrote:
>> What I would like to do is get the desktop window so that I can display a
>> fake live image of the empty desktop as a background to my full-screen
>> window switcher, so that I can imply that the windows have flown up and
>> rearranged themselves on the window switcher, similar to GNOME Shell, but
>> without the 3D effects or GL stuff.
>> At the moment I have something like this:
>> WnckWindow * lightdash_compositor_get_root_window (LightdashCompositor
>> *compositor)
>> {
>>GList *li;
>>
>>for (li = wnck_screen_get_windows (compositor->screen); li != NULL; li =
>> li->next)
>>{
>>WnckWindow *win = WNCK_WINDOW (li->data);
>>if (wnck_window_get_window_type (win) == WNCK_WINDOW_DESKTOP)
>>{
>>return win;
>>}
>>}
>>return NULL;
>> }
>> How could I do this?
>
> You don’t, the compositor does. If you need that, you ask the compositor to
> do it, because only the compositor knows the content of other clients’
> surfaces.
> That would require additions to the protocol. If you are interested, please
> file an issue on GitHub so we can discuss the details.
I would like my window switcher client to draw a semitransparent background
over my fake desktop image, so that it basically looks like GNOME Shell's
Activities Overview. It will then draw the UI elements on top of the
background. Basically like this:
UI elements (top)
Semitransparent UI background
Fake full-screen live desktop image (bottom)
If some elements are rendered by my client and some are rendered by the
compositor, how do I ensure they are always rendered in the right order, i.e.
that the fake desktop image does not obscure the UI chrome?
Regards
adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
> On 1 May 2019, at 10:34, Pekka Paalanen wrote: > > The privacy of the protocol extension, the installed wayland global > really, is achieved in > https://gitlab.freedesktop.org/wayland/weston/blob/master/desktop-shell/shell.c#L4366 > >shell->child.client = weston_client_start(shell->compositor, > shell->client); > > which creates the Wayland connection before forking the child > process and bind_desktop_shell() then verifying the client trying > to bind to the global is the client that was forked. > What do I pass as the "path" parameter to weston_client_start? How do I obtain the value that I pass as "path"? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
> On 17 May 2019, at 09:10, Pekka Paalanen wrote: > > Hi, > > you forgot to use 'name'. > Thanks, that's fixed it! > you should not include that in a > client program. > Guess what I did :p Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Protocol extensions using libweston core functions
I wrote a compositor with a window switcher protocol. The core libweston-desktop function implementations such as surface_added are in shell.c, while the window switcher code is in window-switcher.c. When a new window is opened (a new surface is added), the window switcher will need to be updated with information about this new window. However, the surface_added function in shell.c doesn't know about the window switcher protocol. What is the best way to connect these two parts of the code? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
On Thu, 2019-05-16 at 11:58 +0300, Pekka Paalanen wrote:
>
> you should run an actual event loop in the client, which will then
> flush your requests to the compositor. Your issue seems to be a
> missing
> flush.
>
> See also https://wayland.freedesktop.org/extras.html "Protocol
> dumpers"
> and the link "is not enough".
>
> See: wl_display_flush()
>
I'm not sure exactly what you mean. I tried the following, but it still
doesn't work:
void global_add(void *our_data,
struct wl_registry *registry,
uint32_t name,
const char *interface,
uint32_t version) {
if (strcmp(interface, "xyz_shell") == 0) {
struct xyz_shell *xshell = NULL;
xshell = wl_registry_bind (registry, 1, _shell_interface,
1);
wl_display_flush (display);
}
}
...
void idle ()
{
registry = wl_display_get_registry (display);
wl_registry_add_listener(registry, _listener, NULL);
wl_display_flush (display);
wl_display_dispatch (display);
wl_display_dispatch (display);
wl_display_flush (display);
}
int main (intargc,
char **argv)
{
struct wl_event_loop *event_loop = wl_event_loop_create ();
wl_event_loop_add_idle (event_loop, idle, NULL);
while (true)
{
wl_event_loop_dispatch (event_loop, 0);
}
return 0;
}
I also tried wl_display_get_event_loop() and tried to add_idle() to
that, but that caused the client to segfault.
I tried putting wl_display_flush() wherever I could think of but to no
avail.
Regards
adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
On Wed, 2019-05-01 at 12:34 +0300, Pekka Paalanen wrote:
>
> it is all just the normal Wayland protocol exchange but with a new
> interface of your own design. I'm not sure if there is a really
> minimal example, but I'll list at least some.
>
> One example of such private protocol extension is
> https://gitlab.freedesktop.org/wayland/weston/blob/master/protocol/weston-desktop-shell.xml
>
I wrote a test client to test an initial limited implementation of my
protocol. WAYLAND_DEBUG indicates that my client binds to the
interface, but my protocol's server-side bind() function doesn't run.
Here is some of my code:
Server-side:
static void
bind_desktop_shell(struct wl_client *client,
void *data, uint32_t version, uint32_t id)
{
// This log message never appears
weston_log ("\nbind desktop shell\n");
}
void shell_init ()
{
wl_global_create (server->compositor->wl_display,
_shell_interface, 1,
server, bind_desktop_shell);
}
Client-side:
void global_add(void *our_data,
struct wl_registry *registry,
uint32_t name,
const char *interface,
uint32_t version) {
if (strcmp(interface, "xyz_shell") == 0) {
struct xyz_shell *xshell = NULL;
xshell = wl_registry_bind (registry, 1, _shell_interface,
1);
}
}
int main (intargc,
char **argv)
{
display = wl_display_connect (NULL);
registry = wl_display_get_registry (display);
wl_registry_add_listener(registry, _listener, NULL);
wl_display_dispatch (display);
wl_display_dispatch (display);
return 0;
}
How can I fix this?
Regards
adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
> On 10 May 2019, at 08:48, adlo wrote: > > I put a call to weston_log() in my server-side bind function and then called > wl_global_create() in my client. I was expecting to see my log entry printed > to the screen but I got nothing. > > What could be going on? I meant wl_registry_bind(), not wl_global_create(). I called wl_registry_bind() in my client, but nothing seemed to happen. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
On 9 May 2019, at 10:43, adlo wrote: >> On 1 May 2019, at 10:34, Pekka Paalanen wrote: >> >> it is all just the normal Wayland protocol exchange but with a new >> interface of your own design. I'm not sure if there is a really >> minimal example, but I'll list at least some. >> >> One example of such private protocol extension is >> https://gitlab.freedesktop.org/wayland/weston/blob/master/protocol/weston-desktop-shell.xml >> > > I added a call to wl_global_create(). I also created a test client that calls > wl_registry_bind(), but my bind function doesn't seem to run, and > wl_registry_bind returns NULL. How can I resolve this? > > (Is it OK to just pass the number 1 as the name parameter for > wl_registry_bind?) I put a call to weston_log() in my server-side bind function and then called wl_global_create() in my client. I was expecting to see my log entry printed to the screen but I got nothing. What could be going on? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
> On 1 May 2019, at 10:34, Pekka Paalanen wrote:
>
> it is all just the normal Wayland protocol exchange but with a new
> interface of your own design. I'm not sure if there is a really
> minimal example, but I'll list at least some.
>
> One example of such private protocol extension is
> https://gitlab.freedesktop.org/wayland/weston/blob/master/protocol/weston-desktop-shell.xml
>
> The server-side implementation of it is in shell.c and the
> entrypoint to that is
> https://gitlab.freedesktop.org/wayland/weston/blob/master/desktop-shell/shell.c#L5143
>
>wl_global_create(ec->wl_display,
> _desktop_shell_interface, 1,
> shell, bind_desktop_shell)
>
> which installs the protocol extension in the compositor. You can
> see everything about the implementation by following all callbacks
> that get registered, starting with bind_desktop_shell().
>
> The privacy of the protocol extension, the installed wayland global
> really, is achieved in
> https://gitlab.freedesktop.org/wayland/weston/blob/master/desktop-shell/shell.c#L4366
>
>shell->child.client = weston_client_start(shell->compositor,
> shell->client);
>
> which creates the Wayland connection before forking the child
> process and bind_desktop_shell() then verifying the client trying
> to bind to the global is the client that was forked.
>
>
> The client-side implementation is in desktop-shell.c with the entry
> point at
> https://gitlab.freedesktop.org/wayland/weston/blob/master/clients/desktop-shell.c#L1392
>
>if (!strcmp(interface, "weston_desktop_shell")) {
>desktop->shell = display_bind(desktop->display,
> id,
> _desktop_shell_interface,
> 1);
>weston_desktop_shell_add_listener(desktop->shell,
> ,
> desktop);
I added a call to wl_global_create(). I also created a test client that calls
wl_registry_bind(), but my bind function doesn't seem to run, and
wl_registry_bind returns NULL. How can I resolve this?
(Is it OK to just pass the number 1 as the name parameter for wl_registry_bind?)
Regards
adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
On Wed, 2019-05-01 at 12:34 +0300, Pekka Paalanen wrote: > > it is all just the normal Wayland protocol exchange but with a new > interface of your own design. I'm not sure if there is a really > minimal example, but I'll list at least some. > > One example of such private protocol extension is > https://gitlab.freedesktop.org/wayland/weston/blob/master/protocol/weston-desktop-shell.xml > > > The privacy of the protocol extension, the installed wayland global > really, is achieved in > https://gitlab.freedesktop.org/wayland/weston/blob/master/desktop-shell/shell.c#L4366 > > shell->child.client = weston_client_start(shell->compositor, > shell->client); > > which creates the Wayland connection before forking the child > process and bind_desktop_shell() then verifying the client trying > to bind to the global is the client that was forked. > Does the client have to be a separate object file? Is it possible to simply call the client's init function directly and then fork? Is that how this works? Have I understood this correctly? How do I get the correct path to pass to weston_client_start()? How does it find my object file? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
wayland-wall
It seems that the wayland-wall and weston-wall repositories have disappeared. Any chance of them being reinstated? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
> On 1 May 2019, at 10:34, Pekka Paalanen wrote: > > Hi adlo, > > it is all just the normal Wayland protocol exchange but with a new > interface of your own design. I'm not sure if there is a really > minimal example, but I'll list at least some. > > One example of such private protocol extension is > https://gitlab.freedesktop.org/wayland/weston/blob/master/protocol/weston-desktop-shell.xml How do I ensure that the GtkWindows open on *my* compositor's display? How do I get GTK to find my compositor and connect to it? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
On Fri, 2019-05-03 at 11:02 +0100, adlo wrote: > > On 3 May 2019, at 10:20, Pekka Paalanen > > wrote: > > > > your Makefile.am needs the rules to generate the headers and .c > > files. > > > > I tried copying an edited Makefile.am from the wayland-protocols git > repository, but it complained about GNU-isms. Is there anything else > I need to do other than just specifying the location of the .xml > files? It's OK, I've managed to do it, like this: protocol/xyz-client-protocol.h : $(top_srcdir)/protocol/xyz.xml $(AM_V_GEN) $(wayland_scanner) client-header $(top_srcdir)/protocol/xyz.xml $(top_srcdir)/protocol/xyz-client- protocol.h Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
> On 3 May 2019, at 10:20, Pekka Paalanen wrote: > > your Makefile.am needs the rules to generate the headers and .c files. > >> I tried copying an edited Makefile.am from the wayland-protocols git repository, but it complained about GNU-isms. Is there anything else I need to do other than just specifying the location of the .xml files? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
On Wed, 2019-05-01 at 12:34 +0300, Pekka Paalanen wrote:
>
> it is all just the normal Wayland protocol exchange but with a new
> interface of your own design. I'm not sure if there is a really
> minimal example, but I'll list at least some.
>
> One example of such private protocol extension is
> https://gitlab.freedesktop.org/wayland/weston/blob/master/protocol/weston-desktop-shell.xml
>
>
autotools doesn't seem to be generating the header files. I've put
AC_ARG_VAR([wayland_scanner], [The wayland-scanner executable])
AC_PATH_PROG([wayland_scanner], [wayland-scanner])
if test x$wayland_scanner = x; then
if test "x$cross_compiling" != "xyes"; then
PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner
wayland-scanner`
else
AC_MSG_WARN([You are cross compiling without wayland-
scanner in your path. make check will fail.])
fi
fi
in my configure.ac.in. What else do I need to do?
In the meantime, I worked around it by running wayland-scanner and
manually generating the header files, but when trying to do this:
static const struct xyz_interface xyz_implementation =
{
};
...
wl_global_create (server->compositor->wl_display,
_interface, 1,
server, bind_desktop_shell);
the compiler gave me messages like "xyz_implementation has initializer
but incomplete type" and "storage size of xyz_implementation isn't
known" How can I resolve this?
Also, what's the best way to include my private protocol's header
files, being as my code is in $(topdir)/src and the protocol headers
are in $(topdir)/protocols?
Regards
adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
> On 29 Oct 2018, at 09:33, Pekka Paalanen wrote: > > the only opinionated advice I can give you is don't do it. Instead, put > the GTK stuff in a separate process, let your compositor fork & exec > it, and talk to it through your own private protocol extension for the > special bits you need. What are the basics for creating a private protocol extension, i.e. what's the minimum boilerplate code needed? What's a simple example of how to implement a request between the two processes? The Weston source code is difficult to follow. How do I allow the child process to call functions and pass data to the parent and vice versa? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Using libweston with GTK/GDK
How do I run a GTK/GDK main loop from inside a libweston compositor? If I want to use functions such as gdk_display_get_default () to get my compositor's GdkDisplay, how do I guarantee that my compositor's display exists? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [writing a compositor] Window does not return to previous position on unmaximize
As far as I can tell my code looks the same as Weston's code. What might I be
doing differently that results in the windows not returning to their original
position?
Regards
adlo
> On 25 Sep 2018, at 04:41, adlo wrote:
>
> Here is some more code that I forgot to include:
>
> static void
> unset_maximized(struct ShellSurface *shsurf)
> {
>struct weston_surface *surface =
>weston_desktop_surface_get_surface(shsurf-
>> desktop_surface);
>
>if (shsurf->saved_position_valid)
>weston_view_set_position(shsurf->view,
> shsurf->saved_x, shsurf-
>> saved_y);
>
> shsurf->saved_position_valid = false;
> }
>
> Regards
>
> adlo
>
>
>> On Mon, 2018-09-24 at 04:32 +0100, adlo wrote:
>> I am writing a compositor using libweston. When unmaximizing a
>> window,
>> the window doesn't return to the position it was at before it was
>> maximized. How can I resolve this?
>>
>> Here is my code:
>>
>> static void
>> set_maximized_position (struct ShellSurface *shsurf)
>> {
>>pixman_rectangle32_t area;
>>struct weston_geometry geometry;
>>
>> area.x = shsurf->surface->output->x;
>> area.y = shsurf->surface->output->y;
>>
>>geometry = weston_desktop_surface_get_geometry(shsurf-
>>> desktop_surface);
>>
>>weston_view_set_position(shsurf->view,
>> area.x - geometry.x,
>> area.y - geometry.y);
>> }
>>
>> static void
>> map(struct TestServer *shell, struct ShellSurface *shsurf,
>>int32_t sx, int32_t sy)
>> {
>> if (shsurf->maximized)
>>set_maximized_position (shsurf);
>>weston_view_update_transform(shsurf->view);
>>
>> }
>>
>> static void
>> desktop_surface_committed(struct weston_desktop_surface
>> *desktop_surface,
>> int32_t sx, int32_t sy, void *data)
>> {
>>struct ShellSurface *shsurf =
>>weston_desktop_surface_get_user_data(desktop_surface);
>>struct weston_surface *surface =
>>weston_desktop_surface_get_surface(desktop_surface);
>>struct weston_view *view = shsurf->view;
>>struct TestServer *shell = data;
>>bool was_fullscreen;
>>bool was_maximized;
>>
>>if (surface->width == 0)
>>return;
>>
>> was_maximized = shsurf->maximized;
>>
>> shsurf->maximized =
>>weston_desktop_surface_get_maximized (desktop_surface);
>>
>>if (!weston_surface_is_mapped(surface))
>>map(shell, shsurf, sx, sy);
>>
>> if (was_maximized == shsurf->maximized)
>>return;
>>
>> if (was_maximized)
>>unset_maximized (shsurf);
>>
>> if (shsurf->maximized && !shsurf->saved_position_valid)
>>{
>>
>> shsurf->saved_x = shsurf->view->geometry.x;
>> shsurf->saved_y = shsurf->view->geometry.y;
>> shsurf->saved_position_valid = true;
>>}
>>
>> weston_view_set_position (shsurf->view,
>>shsurf->saved_x, shsurf->saved_y);
>>
>> if (shsurf->maximized)
>>set_maximized_position (shsurf);
>>
>> }
>>
>> An earlier version of the rest of my code can be found at:
>>
>>
> https://github.com/adlocode/test-libweston-desktop/blob/master/shell.c
>>
>> Regards
>>
>> adlo
>>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [writing a compositor] Window does not return to previous position on unmaximize
Here is some more code that I forgot to include:
static void
unset_maximized(struct ShellSurface *shsurf)
{
struct weston_surface *surface =
weston_desktop_surface_get_surface(shsurf-
>desktop_surface);
if (shsurf->saved_position_valid)
weston_view_set_position(shsurf->view,
shsurf->saved_x, shsurf-
>saved_y);
shsurf->saved_position_valid = false;
}
Regards
adlo
On Mon, 2018-09-24 at 04:32 +0100, adlo wrote:
> I am writing a compositor using libweston. When unmaximizing a
> window,
> the window doesn't return to the position it was at before it was
> maximized. How can I resolve this?
>
> Here is my code:
>
> static void
> set_maximized_position (struct ShellSurface *shsurf)
> {
> pixman_rectangle32_t area;
> struct weston_geometry geometry;
>
> area.x = shsurf->surface->output->x;
> area.y = shsurf->surface->output->y;
>
> geometry = weston_desktop_surface_get_geometry(shsurf-
> > desktop_surface);
>
> weston_view_set_position(shsurf->view,
>area.x - geometry.x,
>area.y - geometry.y);
> }
>
> static void
> map(struct TestServer *shell, struct ShellSurface *shsurf,
> int32_t sx, int32_t sy)
> {
> if (shsurf->maximized)
> set_maximized_position (shsurf);
> weston_view_update_transform(shsurf->view);
>
> }
>
> static void
> desktop_surface_committed(struct weston_desktop_surface
> *desktop_surface,
> int32_t sx, int32_t sy, void *data)
> {
> struct ShellSurface *shsurf =
> weston_desktop_surface_get_user_data(desktop_surface);
> struct weston_surface *surface =
> weston_desktop_surface_get_surface(desktop_surface);
> struct weston_view *view = shsurf->view;
> struct TestServer *shell = data;
> bool was_fullscreen;
> bool was_maximized;
>
> if (surface->width == 0)
> return;
>
> was_maximized = shsurf->maximized;
>
> shsurf->maximized =
> weston_desktop_surface_get_maximized (desktop_surface);
>
> if (!weston_surface_is_mapped(surface))
> map(shell, shsurf, sx, sy);
>
> if (was_maximized == shsurf->maximized)
> return;
>
> if (was_maximized)
> unset_maximized (shsurf);
>
> if (shsurf->maximized && !shsurf->saved_position_valid)
> {
>
> shsurf->saved_x = shsurf->view->geometry.x;
> shsurf->saved_y = shsurf->view->geometry.y;
> shsurf->saved_position_valid = true;
> }
>
> weston_view_set_position (shsurf->view,
> shsurf->saved_x, shsurf->saved_y);
>
> if (shsurf->maximized)
> set_maximized_position (shsurf);
>
> }
>
> An earlier version of the rest of my code can be found at:
>
>
https://github.com/adlocode/test-libweston-desktop/blob/master/shell.c
>
> Regards
>
> adlo
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[writing a compositor] Window does not return to previous position on unmaximize
I am writing a compositor using libweston. When unmaximizing a window,
the window doesn't return to the position it was at before it was
maximized. How can I resolve this?
Here is my code:
static void
set_maximized_position (struct ShellSurface *shsurf)
{
pixman_rectangle32_t area;
struct weston_geometry geometry;
area.x = shsurf->surface->output->x;
area.y = shsurf->surface->output->y;
geometry = weston_desktop_surface_get_geometry(shsurf-
>desktop_surface);
weston_view_set_position(shsurf->view,
area.x - geometry.x,
area.y - geometry.y);
}
static void
map(struct TestServer *shell, struct ShellSurface *shsurf,
int32_t sx, int32_t sy)
{
if (shsurf->maximized)
set_maximized_position (shsurf);
weston_view_update_transform(shsurf->view);
}
static void
desktop_surface_committed(struct weston_desktop_surface
*desktop_surface,
int32_t sx, int32_t sy, void *data)
{
struct ShellSurface *shsurf =
weston_desktop_surface_get_user_data(desktop_surface);
struct weston_surface *surface =
weston_desktop_surface_get_surface(desktop_surface);
struct weston_view *view = shsurf->view;
struct TestServer *shell = data;
bool was_fullscreen;
bool was_maximized;
if (surface->width == 0)
return;
was_maximized = shsurf->maximized;
shsurf->maximized =
weston_desktop_surface_get_maximized (desktop_surface);
if (!weston_surface_is_mapped(surface))
map(shell, shsurf, sx, sy);
if (was_maximized == shsurf->maximized)
return;
if (was_maximized)
unset_maximized (shsurf);
if (shsurf->maximized && !shsurf->saved_position_valid)
{
shsurf->saved_x = shsurf->view->geometry.x;
shsurf->saved_y = shsurf->view->geometry.y;
shsurf->saved_position_valid = true;
}
weston_view_set_position (shsurf->view,
shsurf->saved_x, shsurf->saved_y);
if (shsurf->maximized)
set_maximized_position (shsurf);
}
An earlier version of the rest of my code can be found at:
https://github.com/adlocode/test-libweston-desktop/blob/master/shell.c
Regards
adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
What has happened to wayland-wall?
I no longer seem to be able to find the wayland-wall repository on GitHub. Just wondering what has happened to it? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [writing a compositor] Compositor freezes when popup menu clicked
It seems to particularly refer to this part of the code:
https://github.com/adlocode/test-libweston-desktop/blob/master/shell.c#L179
If I remove the calls to weston_layer_entry_remove() and/or
weston_layer_entry_insert(), the problem disappears. Of course this means
windows no longer raise when clicked.
Are there any possible solutions for this problem?
Regards
adlo
> On 27 Jul 2018, at 05:44, adlo wrote:
>
> Any ideas?
>
> The rest of my code can be found at:
> https://github.com/adlocode/test-libweston-desktop
>
> Regards
>
> adlo
>
>
>> On Tue, 2018-07-17 at 09:21 +0100, adlo wrote:
>> I am writing a compositor using libweston. I am attempting to
>> implement raising windows on click. It mostly works, but it has
>> introduced a regression where the compositor freezes when I click on
>> a popup menu, such as those in gedit.
>>
>> Here is my code:
>>
>> static void click_to_activate_binding (struct weston_pointer
>> *pointer,
>> const struct timespec *time,
>> uint32_t button,
>> void *data)
>> {
>> struct TestServer *server = data;
>> struct TestServerSurface *shsurf;
>> struct weston_seat *s;
>> struct weston_surface *main_surface;
>>
>> main_surface = weston_surface_get_main_surface (pointer->focus-
>>> surface);
>> shsurf = weston_desktop_surface_get_user_data
>> (weston_surface_get_desktop_surface
>>(main_surface));
>> struct weston_surface *surface = weston_desktop_surface_get_surface
>> (shsurf->desktop_surface);
>>
>> wl_list_for_each (s, >compositor->seat_list, link)
>>{
>> weston_view_activate (pointer->focus, s,
>>WESTON_ACTIVATE_FLAG_CLICKED |
>>WESTON_ACTIVATE_FLAG_CONFIGURE);
>> weston_seat_set_keyboard_focus (s, pointer->focus->surface);
>> weston_view_geometry_dirty (shsurf->view);
>> weston_layer_entry_remove (>focus->layer_link);
>> weston_layer_entry_insert (>surfaces_layer.view_list,
>> >focus->layer_link);
>> weston_view_geometry_dirty (shsurf->view);
>> weston_surface_damage (main_surface);
>> weston_desktop_surface_propagate_layer (shsurf-
>>> desktop_surface);
>>}
>>
>> }
>>
>> How can I resolve this?
>>
>> Regards
>>
>> adlo
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [writing a compositor] Compositor freezes when popup menu clicked
Any ideas?
The rest of my code can be found at:
https://github.com/adlocode/test-libweston-desktop
Regards
adlo
On Tue, 2018-07-17 at 09:21 +0100, adlo wrote:
> I am writing a compositor using libweston. I am attempting to
> implement raising windows on click. It mostly works, but it has
> introduced a regression where the compositor freezes when I click on
> a popup menu, such as those in gedit.
>
> Here is my code:
>
> static void click_to_activate_binding (struct weston_pointer
> *pointer,
>const struct timespec *time,
>uint32_t button,
>void *data)
> {
> struct TestServer *server = data;
> struct TestServerSurface *shsurf;
> struct weston_seat *s;
> struct weston_surface *main_surface;
>
> main_surface = weston_surface_get_main_surface (pointer->focus-
> >surface);
> shsurf = weston_desktop_surface_get_user_data
> (weston_surface_get_desktop_surface
> (main_surface));
> struct weston_surface *surface = weston_desktop_surface_get_surface
> (shsurf->desktop_surface);
>
> wl_list_for_each (s, >compositor->seat_list, link)
> {
> weston_view_activate (pointer->focus, s,
> WESTON_ACTIVATE_FLAG_CLICKED |
> WESTON_ACTIVATE_FLAG_CONFIGURE);
> weston_seat_set_keyboard_focus (s, pointer->focus->surface);
> weston_view_geometry_dirty (shsurf->view);
> weston_layer_entry_remove (>focus->layer_link);
> weston_layer_entry_insert (>surfaces_layer.view_list,
> >focus->layer_link);
> weston_view_geometry_dirty (shsurf->view);
> weston_surface_damage (main_surface);
> weston_desktop_surface_propagate_layer (shsurf-
> >desktop_surface);
> }
>
> }
>
> How can I resolve this?
>
> Regards
>
> adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[writing a compositor] Compositor freezes when popup menu clicked
I am writing a compositor using libweston. I am attempting to implement raising
windows on click. It mostly works, but it has introduced a regression where the
compositor freezes when I click on a popup menu, such as those in gedit.
Here is my code:
static void click_to_activate_binding (struct weston_pointer *pointer,
const struct timespec *time,
uint32_t button,
void *data)
{
struct TestServer *server = data;
struct TestServerSurface *shsurf;
struct weston_seat *s;
struct weston_surface *main_surface;
main_surface = weston_surface_get_main_surface (pointer->focus->surface);
shsurf = weston_desktop_surface_get_user_data
(weston_surface_get_desktop_surface
(main_surface));
struct weston_surface *surface = weston_desktop_surface_get_surface
(shsurf->desktop_surface);
wl_list_for_each (s, >compositor->seat_list, link)
{
weston_view_activate (pointer->focus, s,
WESTON_ACTIVATE_FLAG_CLICKED |
WESTON_ACTIVATE_FLAG_CONFIGURE);
weston_seat_set_keyboard_focus (s, pointer->focus->surface);
weston_view_geometry_dirty (shsurf->view);
weston_layer_entry_remove (>focus->layer_link);
weston_layer_entry_insert (>surfaces_layer.view_list,
>focus->layer_link);
weston_view_geometry_dirty (shsurf->view);
weston_surface_damage (main_surface);
weston_desktop_surface_propagate_layer (shsurf->desktop_surface);
}
}
How can I resolve this?
Regards
adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[writing a compositor] Displaying something on the screen
I am attempting to write a simple test compositor using libweston. Here is my code so far: https://github.com/adlocode/test-libweston-desktop What else do I need to do in order to get it to the point where something appears on the screen, such as a rectangle of solid colour? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[writing a compositor] wl_display_add_socket_auto fails
I am attempting to write a test compositor using libweston. I want to run it in a window on GNOME Shell, so I am using the Wayland backend. When I call wl_display_add_socket_auto, it fails with the error message: unable to lock lockfile /run/user/1000/wayland-0.lock, maybe another compositor is running How can I resolve this? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libweston program segfaults on weston_compositor_load_backend
On Fri, 2018-05-04 at 10:13 +0300, Pekka Paalanen wrote: > > Is that perhaps the very first call to weston_log()? > > You need to initialize the logging mechanism before anything can call > weston_log(). Yeah, it's awkward, could probably be improved, but > OTOH > one would always want all log messages going to the same place, so > you > really do want to initialize the logging before any logging happens > to > avoid losing messages. > > The crucial call to make is weston_log_set_handler() with non-NULL > arguments before any other libweston calls. > That's fixed it, thank you! Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libweston program segfaults on weston_compositor_load_backend
On Thu, 2018-05-03 at 14:12 +0300, Pekka Paalanen wrote: > > what's the backtrace from gdb for that? > Is this any help? #0 0x in () #1 0x7799c88c in weston_log (fmt=fmt@entry=0x779b6a7e "Loading module '%s'\n") at libweston/log.c:75 #2 0x779a603c in weston_load_module (name=name@entry=0x779 b6b24 "wayland-backend.so", entrypoint=entrypoint@entry=0x779b6aae "weston_backend_init") at libweston/compositor.c:6375 #3 0x779a6264 in weston_compositor_load_backend (compositor=0x611090, backend=backend@entry= WESTON_BACKEND_WAYLAND, config_base=config_base@entry=0x7fffdc5 0) at libweston/compositor.c:6485 #4 0x00400704 in main (argc=, argv=) at ../main.c:42 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
libweston program segfaults on weston_compositor_load_backend
I am trying to write a simple test compositor using libweston, but it
segfaults on weston_compositor_load_backend.
Here is my code:
main.c:
#include
#include
#include
#include
#include
#include
#include
#include
int main (intargc,
char **argv)
{
struct wl_display *display;
struct weston_compositor *ec;
int ret = 0;
display = wl_display_create ();
ec = weston_compositor_create (display, NULL);
ec->default_pointer_grab = NULL;
ec->vt_switching = true;
ec->repaint_msec = 16;
ec->idle_time = 300;
struct weston_wayland_backend_config config = {{0, }};
config.base.struct_version =
WESTON_WAYLAND_BACKEND_CONFIG_VERSION;
config.base.struct_size = sizeof (struct
weston_wayland_backend_config);
config.cursor_size = 32;
config.display_name = 0;
config.use_pixman = 0;
config.sprawl = 0;
config.fullscreen = 0;
config.cursor_theme = NULL;
ret = weston_compositor_load_backend (ec,
WESTON_BACKEND_WAYLAND, );
return 0;
}
meson.build:
project('test-libweston-desktop', 'c',
default_options: 'c_std=c11')
wayland_server = dependency('wayland-server')
wayland_client = dependency('wayland-client')
wayland_protocols = dependency('wayland-protocols')
libweston = dependency ('libweston-5')
libweston_desktop= dependency ('libweston-desktop-5')
libinput = dependency('libinput')
pixman = dependency('pixman-1')
xkbcommon = dependency('xkbcommon')
egl = dependency('egl')
libevdev = dependency('libevdev')
executable('test-libweston-desktop', 'main.c', dependencies :
[wayland_server, wayland_client, wayland_protocols, libinput,
libweston, pixman, xkbcommon, egl, libevdev, libweston_desktop])
How can I resolve my issue?
Regards
adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Writing a basic compositor using libweston-desktop
On Fri, Jun 2, 2017 at 1:51 AM, adlo <adloco...@gmail.com> wrote: > How do I write a program that spawns a simple compositor instance on a > nested Wayland window using libweston-desktop and the Wayland-on-Wayland > backend? What are the absolute basics needed to get something on the screen > using libweston-desktop and the nested Wayland-on-Wayland backend? > What about this? Am I on the right lines? What would I need to do to make my compositor appear in a window? struct weston_desktop *desktop; struct wl_display *display; struct weston_compositor *compositor; const struct weston_desktop_api *api; struct weston_layer base; display = wl_display_create (); compositor = weston_compositor_create (display, NULL); weston_layer_init (, compositor); weston_layer_set_position (, WESTON_LAYER_POSITION_BACKGROUND); desktop = weston_desktop_create (compositor, api, NULL); Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Writing a basic compositor using libweston-desktop
How do I write a program that spawns a simple compositor instance on a nested Wayland window using libweston-desktop and the Wayland-on-Wayland backend? What are the absolute basics needed to get something on the screen using libweston-desktop and the nested Wayland-on-Wayland backend? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libweston versions and tutorials
> On 31 May 2017, at 13:54, Quentin Glidic <sardemff7+wayl...@sardemff7.net> > wrote: > > One advice I’d have to give is to use libweston-desktop, that abstract a lot > of protocol stuff and just let you manage toplevel surfaces without worrying > about shell protocols, popups and other boring things like that. :-) How do I initialise a simple compositor using libweston-desktop? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libweston versions and tutorials
On Wed, May 31, 2017 at 1:54 PM, Quentin Glidic < sardemff7+wayl...@sardemff7.net> wrote: > On 5/31/17 2:37 PM, adlo wrote: > >> Is libweston 1.0 good enough for writing a compositor? >> > > Yes, but each major version is adding or changing API to make it simpler > to write a compositor. Specifically, libweston 2 has introduced a much > nicer output API, thanks to Armin’s GSoC work. > > > Are there any tutorials or simple examples for writing a compositor using >> any version of libweston? >> > > I think someone started something, but it’s probably outdated by now. > > One advice I’d have to give is to use libweston-desktop, that abstract a > lot of protocol stuff and just let you manage toplevel surfaces without > worrying about shell protocols, popups and other boring things like that. > :-) I compiled my own libweston by hand, but when I try to run my compiled Weston on a nested GNOME Wayland-on-Wayland session, I get the error message "Failed to load module: /lib/libweston-3/wayland-backend.so: cannot open shared object file: No such file or directory". Any ideas on why this is happening? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
libweston versions and tutorials
Is libweston 1.0 good enough for writing a compositor? Are there any tutorials or simple examples for writing a compositor using any version of libweston? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiling wayhouse against local libweston
On Tue, May 30, 2017 at 2:24 AM, adlo <adloco...@gmail.com> wrote: > How do I compile wayhouse against my locally compiled libweston? > Can I compile wayhouse against Fedora 25 stock libweston instead of a git version? Is Fedora's libweston up-to-date enough for wayhouse? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiled Weston fails to start
On Tue, May 30, 2017 at 12:30 AM, adlo <adloco...@gmail.com> wrote: > I have built Weston from source. When trying to run it in a nested window > on GNOME Wayland, it gives me the error message "Failed to load module: > /lib/libweston-3/wayland-backend.so: cannot open shared object file: No > such file or directory" > > How can I resolve this? > I suspect that it may be trying to load the global/stock Wayland backend instead of my locally compiled one. I have tried passing --enable-wayland-compositor to autogen.sh but this does not seem to make any difference. Does anyone have any ideas? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Compiling wayhouse against local libweston
How do I compile wayhouse against my locally compiled libweston? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Compiled Weston fails to start
I have built Weston from source. When trying to run it in a nested window on GNOME Wayland, it gives me the error message "Failed to load module: /lib/libweston-3/wayland-backend.so: cannot open shared object file: No such file or directory" How can I resolve this? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Return values in Wayland XML specification
> On 24 May 2017, at 16:43, Quentin Glidic <sardemff7+wayl...@sardemff7.net>
> wrote:
>
> There is no need, because the compositor is supposed to list only relevant
> surfaces.
What I would like to do is get the desktop window so that I can display a fake
live image of the empty desktop as a background to my full-screen window
switcher, so that I can imply that the windows have flown up and rearranged
themselves on the window switcher, similar to GNOME Shell, but without the 3D
effects or GL stuff.
At the moment I have something like this:
WnckWindow * lightdash_compositor_get_root_window (LightdashCompositor
*compositor)
{
GList *li;
for (li = wnck_screen_get_windows (compositor->screen); li != NULL; li
= li->next)
{
WnckWindow *win = WNCK_WINDOW (li->data);
if (wnck_window_get_window_type (win) == WNCK_WINDOW_DESKTOP)
{
return win;
}
}
return NULL;
}
How could I do this?
Regards
adlo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Return values in Wayland XML specification
> On 15 May 2017, at 10:52, Quentin Glidic <sardemff7+wayl...@sardemff7.net> > wrote: > > If you are writing/porting a window switcher, please consider using Wayland > Wall window-switcher protocol[1]. If you are not, please don’t, as this > protocol is very specific to switchers (it has "switch_to" and "close" > requests). > If you need for more than this protocol offers, or something doesn’t fit your > software, just fill an issue and we will discuss the possible designs. Can your protocol get the type hint of a window? For example, can I find out if a window is a desktop, panel, or normal window, or whether it is skip tasklist, skip pager etc? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Return values in Wayland XML specification
Do any compositors support this protocol? Regards adlo > On 15 May 2017, at 14:27, Quentin Glidic <sardemff7+wayl...@sardemff7.net> > wrote: > > On 5/15/17 3:13 PM, adlo wrote: >>> On 15 May 2017, at 10:52, Quentin Glidic >>> <sardemff7+wayl...@sardemff7.net> wrote: >>> If you are writing/porting a window switcher, please consider using >>> Wayland Wall window-switcher protocol[1]. If you are not, please >>> don’t, as this protocol is very specific to switchers (it has >>> "switch_to" and "close" requests). If you need for more than this >>> protocol offers, or something doesn’t fit your software, just fill >>> an issue and we will discuss the possible designs. >> Does your protocol have window thumbnails and damage events for these >> thumbnails? How does your protocol compare to KDE's >> org_kde_plasma_windowmanagement? > > KDE protocol seems to be designed for window managers, not window > switchers. My protocol does allow to display thumbnails, but everything > is on the compositor side, the client just ask it to display them at a > specific position of its own surface. > > I believe KDE’s protocol is too complex for simple compositors to use it > easily. > > Cheers, > > -- > > Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Return values in Wayland XML specification
> On 15 May 2017, at 08:46, Pekka Paalanen <ppaala...@gmail.com> wrote: > > Yes, that is a good design suggestion. > > If the events are always sent only as a response to a request, then > there is no need for a 'done' event. The client can send the request > followed by wl_display.sync, and once the sync callback arrives, all > responses have been received. > > But, if the server can spontaneously send a series of events, then you > probably need a 'done' for the client to know when the series is > complete again. What are events? Are they things that are sent by an interface or received by it? How do you link the request with its corresponding response event? If the client sends a get_window request, how does the server know how to respond to it? Do they both need to be specified in the XML? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Return values in Wayland XML specification
> On 15 May 2017, at 10:52, Quentin Glidic <sardemff7+wayl...@sardemff7.net> > wrote: > > If you are writing/porting a window switcher, please consider using Wayland > Wall window-switcher protocol[1]. If you are not, please don’t, as this > protocol is very specific to switchers (it has "switch_to" and "close" > requests). > If you need for more than this protocol offers, or something doesn’t fit your > software, just fill an issue and we will discuss the possible designs. Does your protocol have window thumbnails and damage events for these thumbnails? How does your protocol compare to KDE's org_kde_plasma_windowmanagement? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Return values in Wayland XML specification
> On 26 Apr 2017, at 08:23, Pekka Paalanen <ppaala...@gmail.com> wrote: > > If you need a client to receive something as a reply to a request, you > need to specify an event for delivering it. There are no shortcuts for > that, because each roundtrip makes everything a tiny bit slower, and > that accumulates. Therefore one should reconsider if a roundtrip is > really necessary, or if things could be designed to be asynchronous > instead. For example, getting a list of windows and returning it as an array. How would this be done? How are arrays represented in Wayland XML? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Return values in Wayland XML specification
How are return values specified in the Wayland XML specification? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Kinetic scroll in libinput Xorg driver
> On 25 Oct 2016, at 12:08, Peter Hutterer <peter.hutte...@who-t.net> wrote: > > ok, this will be unpopular with the internets, but the times of "I don't want > to have a DE" are over. yes, you can still do it. you can run scripts in > xinit to set up things, but the vast majority of users will need to/want to > have a DE running that takes care of things dynamically. Hardware has moved > on since the 80s, so has the functionality we've come to expect. It's not > enough anymore to throw a few pieces of metal on the ground and say "here's > your car". you can still do it, but you're now talking about a tiny subset of > users that want things that way. > > so the case of no DE is niche in X, and effectively non-existent in wayland > (because you *need* a compositor). What is the minimum setup that is possible with Wayland? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
Any ideas about this? > On 7 Jun 2016, at 16:04, adlo <adloco...@gmail.com> wrote: > > There are many other protocols that may require handles to windows. It may > make sense for them to all use the same handle protocol. Of course, all of > these different protocols would require different levels and types of > privileges. > > For example, a window switcher application would also need a protocol that > can control windows in many ways, such as minimizing, maximizing, closing, > moving, and focusing them, as well as getting the title of windows. However, > the preview protocol, using the same handle type, would not need to access > these functions. Is it possible to have a non-privileged interface using a > privileged handle without any security issues? > > Also, Derek's reply mentions a "common module framework". How is this > different from a Wayland protocol, and what are its advantages? > > Regards > > adlo > > >> On 1 Jun 2016, at 09:00, Pekka Paalanen <ppaala...@gmail.com> wrote: >> >> On Tue, 31 May 2016 14:49:38 +0100 >> adlo <adloco...@gmail.com> wrote: >> >>>> On 20 May 2016, at 08:50, Pekka Paalanen <ppaala...@gmail.com> wrote: >>>> >>>> You would design a new protocol extension private to Weston, with which >>>> you deliver to your client the handles for top-level windows as they >>>> come and go. >>> >>> This should probably be a separate protocol from the preview >>> protocol. Is it possible to integrate the handle and preview protocol >>> with another protocol, such as xdg-shell, so that the handles are >>> delivered as xdg_surfaces and the preview protocol accepts >>> xdg_surfaces as input? >> >> No. Not for what you would like to use it. That simply is not what >> xdg_surface is for, and none of the xdg_surface API or any other API >> using xdg_surface would apply. So it is totally inappropriate to try to >> shoehorn xdg_surface in there. >> >> The handles would usually represent surfaces that have a xdg_surface >> associated in the originating client, but it makes no sense to try to >> call the handle a xdg_surface. The handles are used completely >> differently than xdg_surfaces. >> >> There is also a practical issue: to create an xdg_surface with >> xdg_shell, you first need a wl_surface. However, you cannot refer to a >> wl_surface of another client. That is the whole reason you need to >> create handles in the first place, to be able to refer to surfaces that >> are not your own. >> >>> Is xdg-shell designed to be used by third-party clients for >>> controlling windows in a similar way to libwnck? Does xdg-shell >>> expose the inner workings of the compositor thus making it unsuitable? >> >> As Jonas said, no. >> >> >> Thanks, >> pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
There are many other protocols that may require handles to windows. It may make sense for them to all use the same handle protocol. Of course, all of these different protocols would require different levels and types of privileges. For example, a window switcher application would also need a protocol that can control windows in many ways, such as minimizing, maximizing, closing, moving, and focusing them, as well as getting the title of windows. However, the preview protocol, using the same handle type, would not need to access these functions. Is it possible to have a non-privileged interface using a privileged handle without any security issues? Also, Derek's reply mentions a "common module framework". How is this different from a Wayland protocol, and what are its advantages? Regards adlo > On 1 Jun 2016, at 09:00, Pekka Paalanen <ppaala...@gmail.com> wrote: > > On Tue, 31 May 2016 14:49:38 +0100 > adlo <adloco...@gmail.com> wrote: > >>> On 20 May 2016, at 08:50, Pekka Paalanen <ppaala...@gmail.com> wrote: >>> >>> You would design a new protocol extension private to Weston, with which >>> you deliver to your client the handles for top-level windows as they >>> come and go. >> >> This should probably be a separate protocol from the preview >> protocol. Is it possible to integrate the handle and preview protocol >> with another protocol, such as xdg-shell, so that the handles are >> delivered as xdg_surfaces and the preview protocol accepts >> xdg_surfaces as input? > > No. Not for what you would like to use it. That simply is not what > xdg_surface is for, and none of the xdg_surface API or any other API > using xdg_surface would apply. So it is totally inappropriate to try to > shoehorn xdg_surface in there. > > The handles would usually represent surfaces that have a xdg_surface > associated in the originating client, but it makes no sense to try to > call the handle a xdg_surface. The handles are used completely > differently than xdg_surfaces. > > There is also a practical issue: to create an xdg_surface with > xdg_shell, you first need a wl_surface. However, you cannot refer to a > wl_surface of another client. That is the whole reason you need to > create handles in the first place, to be able to refer to surfaces that > are not your own. > >> Is xdg-shell designed to be used by third-party clients for >> controlling windows in a similar way to libwnck? Does xdg-shell >> expose the inner workings of the compositor thus making it unsuitable? > > As Jonas said, no. > > > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
> On 20 May 2016, at 08:50, Pekka Paalanen <ppaala...@gmail.com> wrote: > > You would design a new protocol extension private to Weston, with which > you deliver to your client the handles for top-level windows as they > come and go. > This should probably be a separate protocol from the preview protocol. Is it possible to integrate the handle and preview protocol with another protocol, such as xdg-shell, so that the handles are delivered as xdg_surfaces and the preview protocol accepts xdg_surfaces as input? Is xdg-shell designed to be used by third-party clients for controlling windows in a similar way to libwnck? Does xdg-shell expose the inner workings of the compositor thus making it unsuitable? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
> On 11 May 2016, at 09:07, Pekka Paalanen <ppaala...@gmail.com> wrote: > > If some sort of protocol would be needed, then you have to figure out > how to not make it a gaping security breach > What about Wayland Security Modules (libwsm)? In what ways does this fail to address the security issues with privileged interfaces? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
> On 24 May 2016, at 16:06, Pekka Paalanen <ppaala...@gmail.com> wrote: > > The "private to weston" also means it should be a privileged interface: > arbitrary clients must not be able to use it, as it's none of their > concern and could be a security concern. > What about Wayland Security Modules (libwsm)? In what ways does this not solve the security issues of privileged interfaces? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
> On 20 May 2016, at 09:33, Olivier Fourdan <four...@gmail.com> wrote: > > FWIW, if xfce were to support Wayland some day, we'd probably built it > on top of an existing compositor manager (mutter is probably the best > bet for a gtk+ based environment) and just like with GNOME shell, > window previews/thumbnails would be handled in the compositor/shell. Does mutter support pixman 2D software rendering? I believe that xfwm4 supports this through XRender. Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
> On 12 May 2016, at 08:57, Pekka Paalanen <ppaala...@gmail.com> wrote: > > On Wed, 11 May 2016 23:35:01 +0100 > ade low <adloco...@gmail.com> wrote: >> My use case is third-party window switcher applications, such as >> xfdashboard or my program, xfce4-lightdash-plugin: >> https://github.com/adlocode/xfce4-lightdash-plugin > > The implementation of such things would have so much > compositor-internal parts anyway, that making a protocol for it does > not seem tractable to me. Why would anyone bother implementing such > protocol in their compositor? If there is no protocol, what could be an alternative way for third-party window switchers to be implemented on Wayland compositors? > >> A little more tractable plan would be to communicate only surface >>> meta-data to the client, >>> which could then ask the compositor to draw >>> the thumbnails relative to one of the client's surfaces. The client >>> would never have access to window content itself. >> > The very point is, the client would not render the thumbnails at all. > The compositor would. Painting a copy of a window at another location > should be fairly easy in theory. From your client perspective it would > be a little like a special sub-surface whose content magically just > appears on screen. If I wanted to try writing something like this as a Weston extension for testing purposes, how could I get the window's surface? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
