Re: RFC: GtkPreview library
I've done the above. https://github.com/magcius/wakefield Check it out, run make, then run: $ LD_LIBRARY_PATH=. ./test-compositor $ ./test-client-2 Right now it's a very basic prototype -- it doesn't support all functionality, it doesn't dynamically resize the surface the client handed us, and will easily crash, but for a day and a half of work, I think it proves that it can be done. On Tue, Jan 27, 2015 at 5:19 AM, Cosimo Cecchi cosi...@gnome.org wrote: So you're effectively proposing that the transport of the data between plugins and the widget is always Wayland, even if the session is running under X11? That sounds like a good idea to me if it's possible to implement. I would definitely welcome a proof of concept! Thanks, Cosimo On Sun, Jan 25, 2015 at 4:21 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: We could indeed write a tiny Wayland compositor that composited a single wl_surface as a GTK+ widget, and I wouldn't feel too bad about it. We could even do it while under X11, and it might be an interesting proof of concept. I could do a PoC if you guys want. On Jan 25, 2015 8:05 AM, Cosimo Cecchi cosi...@gnome.org wrote: Fair enough, those are good points. To rephrase my last message I am not well-versed in the details of subsurfaces and how they would help in this case, so I will appreciate help to evolve my API proposal in that direction :-) Cosimo On Sun, Jan 25, 2015 at 3:49 PM, Emmanuele Bassi eba...@gmail.com wrote: hi; On 25 January 2015 at 13:31, Philip Withnall phi...@tecnocode.co.uk wrote: That's why my proposal doesn't enforce this specific design; I'm definitely open to think more about how a multi-process design looks like, but I wouldn't want to block until that is figured out. To me, the security and rendering architecture of this seems pretty core in the design, so I _would_ block on figuring it out. It doesn’t feel like the kind of thing which can easily be bolted on or fixed afterwards. I tend to agree; we need to start designing our API with sandboxing and security context separation from the start, these days, otherwise we'll have nothing but grief (in the form of API changes or, worse, complete rewrites) down the line. ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Handling Tablet Buttons in GTK+ on Wayland
Hello, As some of you may be aware, I've been working with Carlos Garnacho in order to implement support in GTK+ for the current draft protocol for using tablets on Wayland. You can find the latest preview branch of weston, modified to work with this protocol, here: https://github.com/Lyude/weston And you can find the WIP branch for GTK+ support here: https://github.com/Lyude/gtk- So, right now we've run into something that we believe needs some more discussion in terms of how it will be implemented: handling tablet buttons in GTK+ with the Wayland backend. Right now, the tablet-support branch of libinput only supports the buttons on the actual styluses for the tablet, not the buttons on the tablet pad, so we only need to worry about those for the time being. The problem is right now with the X11 backend is that these buttons aren't exactly handled in an ideal manner. On the average GNOME setup, gnome-settings-daemon tells xf86-input-wacom which mouse buttons each button on the tablet tool should be mapped to (for example: button #1 on the stylus may be mapped to a right click, and button #2 may be mapped to a left click), and X forwards them to the clients as such. This means that GDK only knows which emulated mouse buttons are being pressed as opposed to the actual tablet tool buttons, and only forwards what it gets from the xf86-input-wacom. So, there isn't even actually any infrastructure in GDK right now to handle actual tablet tool button presses, just mouse button presses. This leaves us with an issue, since the libinput API for tablets doesn't do any such emulation, and there's no emulation for this in the Wayland protocol (and I think it would be a good idea not to add any, IMO any emulation of this manner should be handled by the clients, not the compositor). Since there's quite a few ways to go about it, me and Carlos thought it would be appropriate to bring this up on the mailing list. Let me know what your ideas are. Cheers, Lyude AKA Stephen Chandler Paul signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Handling Tablet Buttons in GTK+ on Wayland
On Tue, Jan 27, 2015 at 03:30:03PM -0500, Lyude wrote: Hello, As some of you may be aware, I've been working with Carlos Garnacho in order to implement support in GTK+ for the current draft protocol for using tablets on Wayland. You can find the latest preview branch of weston, modified to work with this protocol, here: https://github.com/Lyude/weston And you can find the WIP branch for GTK+ support here: https://github.com/Lyude/gtk- So, right now we've run into something that we believe needs some more discussion in terms of how it will be implemented: handling tablet buttons in GTK+ with the Wayland backend. Right now, the tablet-support branch of libinput only supports the buttons on the actual styluses for the tablet, not the buttons on the tablet pad, so we only need to worry about those for the time being. just to give you the libinput plan for this part: we're currently writing a buttonset interface that is somewhat similar to the tablet interface but will handle the tablet buttons and axes present on the pad. A device with multiple capabilities will send events through the interfaces and have those exposes as such. The struct libinput_device will merge event nodes into a single logical device. On a Intuos 5 touch for example you'd get a single struct libinput_device with the capabilities TABLET, TOUCH and BUTTONSET. Wheel events are sent as buttonset event with BUTTONSET_AXIS_WHEEL, etc. Button handling will be similar to the tablet button handling. This is still WIP, and the wayland protocol requirements haven't been scoped yet either. Cheers, Peter The problem is right now with the X11 backend is that these buttons aren't exactly handled in an ideal manner. On the average GNOME setup, gnome-settings-daemon tells xf86-input-wacom which mouse buttons each button on the tablet tool should be mapped to (for example: button #1 on the stylus may be mapped to a right click, and button #2 may be mapped to a left click), and X forwards them to the clients as such. This means that GDK only knows which emulated mouse buttons are being pressed as opposed to the actual tablet tool buttons, and only forwards what it gets from the xf86-input-wacom. So, there isn't even actually any infrastructure in GDK right now to handle actual tablet tool button presses, just mouse button presses. This leaves us with an issue, since the libinput API for tablets doesn't do any such emulation, and there's no emulation for this in the Wayland protocol (and I think it would be a good idea not to add any, IMO any emulation of this manner should be handled by the clients, not the compositor). Since there's quite a few ways to go about it, me and Carlos thought it would be appropriate to bring this up on the mailing list. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 2:23 PM, Paul Davis p...@linuxaudiosystems.com wrote: what happened to the idea of GTK being a cross-platform toolkit? you're seriously proposing building something as significant as a Preview widget around a technology that isn't even deployed on most Linux systems yet, and will almost certainly never be available on other platforms? Paul, I don't think you understand what is being proposed here, and I much dislike the aggressive tone you are imposing on this conversation. Whether to use something different than a Wayland transport on non-Linux platforms is entirely up for debate. I am not familiar with how Windows and OSX implement previews, and whether integration with the native platform APIs is desirable in those cases, but I will point out that a simple shared memory transport can be used with Wayland, which should work fine even on those platforms. Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 5:19 AM, Cosimo Cecchi cosi...@gnome.org wrote: So you're effectively proposing that the transport of the data between plugins and the widget is always Wayland, even if the session is running under X11? That sounds like a good idea to me if it's possible to implement. I would definitely welcome a proof of concept! what happened to the idea of GTK being a cross-platform toolkit? you're seriously proposing building something as significant as a Preview widget around a technology that isn't even deployed on most Linux systems yet, and will almost certainly never be available on other platforms? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 9:42 AM, Cosimo Cecchi cosi...@gnome.org wrote: On Tue, Jan 27, 2015 at 2:23 PM, Paul Davis p...@linuxaudiosystems.com wrote: what happened to the idea of GTK being a cross-platform toolkit? you're seriously proposing building something as significant as a Preview widget around a technology that isn't even deployed on most Linux systems yet, and will almost certainly never be available on other platforms? Paul, I don't think you understand what is being proposed here, and I much dislike the aggressive tone you are imposing on this conversation. Whether to use something different than a Wayland transport on non-Linux platforms is entirely up for debate. I am not familiar with how Windows and OSX implement previews, and whether integration with the native platform APIs is desirable in those cases, but I will point out that a simple shared memory transport can be used with Wayland, which should work fine even on those platforms. I'm not trying to be aggressive. I've been very active at trying to keep GTK functioning and improving on OS X (less so in the immediate past, but a lot more a year or two ago). I understand the appeal of using existing technology (i.e. Wayland) to accomplish something when it appears that it will make it much easier. But if GTK is still at least nominally cross-platform, then surely the place to start is a higher level abstraction of the transport system, and then later to bolt wayland onto that design under the hood, rather than starting with Wayland and then shrugging one's hands and saying do something like Wayland on other platforms? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
So you're effectively proposing that the transport of the data between plugins and the widget is always Wayland, even if the session is running under X11? That sounds like a good idea to me if it's possible to implement. I would definitely welcome a proof of concept! Thanks, Cosimo On Sun, Jan 25, 2015 at 4:21 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: We could indeed write a tiny Wayland compositor that composited a single wl_surface as a GTK+ widget, and I wouldn't feel too bad about it. We could even do it while under X11, and it might be an interesting proof of concept. I could do a PoC if you guys want. On Jan 25, 2015 8:05 AM, Cosimo Cecchi cosi...@gnome.org wrote: Fair enough, those are good points. To rephrase my last message I am not well-versed in the details of subsurfaces and how they would help in this case, so I will appreciate help to evolve my API proposal in that direction :-) Cosimo On Sun, Jan 25, 2015 at 3:49 PM, Emmanuele Bassi eba...@gmail.com wrote: hi; On 25 January 2015 at 13:31, Philip Withnall phi...@tecnocode.co.uk wrote: That's why my proposal doesn't enforce this specific design; I'm definitely open to think more about how a multi-process design looks like, but I wouldn't want to block until that is figured out. To me, the security and rendering architecture of this seems pretty core in the design, so I _would_ block on figuring it out. It doesn’t feel like the kind of thing which can easily be bolted on or fixed afterwards. I tend to agree; we need to start designing our API with sandboxing and security context separation from the start, these days, otherwise we'll have nothing but grief (in the form of API changes or, worse, complete rewrites) down the line. ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
All of this is part of wl_event_loop, which is an unfortunate public API that should probably go away. On Wed, Jan 28, 2015 at 1:21 AM, Philip Chimento philip.chime...@gmail.com wrote: On Tue, Jan 27, 2015 at 8:49 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: Gah. I always get those backwards. I actually typed SCM_RIGHTS and then changed it to SCM_CREDENTIALS. I still don't understand why fd passing is called rights. On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 27/01/15 15:55, Jasper St. Pierre wrote: Wayland requires two features that would perhaps make it unportable: FD passing (SCM_CREDENTIALS), and shared memory (allocate a temporary files, ftruncate it, mmap it, unlink it and then send the fd across the wire). Everything else is just a simple Unix domain socket. Does OS X support those two features? I think you mean SCM_RIGHTS? SCM_RIGHTS is here's a message with an open fd attached. It's how D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite platform, Wayland fd-passing should too. SCM_CREDENTIALS is here's a message with my uid, gid and pid[1] attached, the kernel will check that I haven't lied to you (also called SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a syscall to query those things or both, but most Unixes also have their own unique spelling for the API, because standards are hard.[2] S [1] Strictly speaking the uid, gid and pid I had at the time I opened this socket [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and several platforms (sadly not including Linux) share getpeereid(). For the gory details see libdbus source code. I put it to the test and tried to build Jasper's proof of concept (and therefore Wayland) on OSX. I didn't get very far. Wayland's configure.ac checks for SFD_CLOEXEC and TFD_CLOEXEC which implies that it uses signalfd() and timerfd(), not available on OSX. I guess the replacement would be something with kqueue though I really haven't the faintest idea what I'm talking about there. Wayland also wants clock_gettime() - not insurmountable to provide on OSX but afaik uses a different API, quick googling showed up this: http://stackoverflow.com/a/6725161/172999 PS. Funny thing that this is one of the top results for googling SFD_CLOEXEC, even without adding osx or wayland: http://stackoverflow.com/questions/27864027/sfd-cloexec-wayland Best, -- Philip -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 8:49 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: Gah. I always get those backwards. I actually typed SCM_RIGHTS and then changed it to SCM_CREDENTIALS. I still don't understand why fd passing is called rights. On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 27/01/15 15:55, Jasper St. Pierre wrote: Wayland requires two features that would perhaps make it unportable: FD passing (SCM_CREDENTIALS), and shared memory (allocate a temporary files, ftruncate it, mmap it, unlink it and then send the fd across the wire). Everything else is just a simple Unix domain socket. Does OS X support those two features? I think you mean SCM_RIGHTS? SCM_RIGHTS is here's a message with an open fd attached. It's how D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite platform, Wayland fd-passing should too. SCM_CREDENTIALS is here's a message with my uid, gid and pid[1] attached, the kernel will check that I haven't lied to you (also called SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a syscall to query those things or both, but most Unixes also have their own unique spelling for the API, because standards are hard.[2] S [1] Strictly speaking the uid, gid and pid I had at the time I opened this socket [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and several platforms (sadly not including Linux) share getpeereid(). For the gory details see libdbus source code. I put it to the test and tried to build Jasper's proof of concept (and therefore Wayland) on OSX. I didn't get very far. Wayland's configure.ac checks for SFD_CLOEXEC and TFD_CLOEXEC which implies that it uses signalfd() and timerfd(), not available on OSX. I guess the replacement would be something with kqueue though I really haven't the faintest idea what I'm talking about there. Wayland also wants clock_gettime() - not insurmountable to provide on OSX but afaik uses a different API, quick googling showed up this: http://stackoverflow.com/a/6725161/172999 PS. Funny thing that this is one of the top results for googling SFD_CLOEXEC, even without adding osx or wayland: http://stackoverflow.com/questions/27864027/sfd-cloexec-wayland Best, -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
Gah. I always get those backwards. I actually typed SCM_RIGHTS and then changed it to SCM_CREDENTIALS. I still don't understand why fd passing is called rights. On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 27/01/15 15:55, Jasper St. Pierre wrote: Wayland requires two features that would perhaps make it unportable: FD passing (SCM_CREDENTIALS), and shared memory (allocate a temporary files, ftruncate it, mmap it, unlink it and then send the fd across the wire). Everything else is just a simple Unix domain socket. Does OS X support those two features? I think you mean SCM_RIGHTS? SCM_RIGHTS is here's a message with an open fd attached. It's how D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite platform, Wayland fd-passing should too. SCM_CREDENTIALS is here's a message with my uid, gid and pid[1] attached, the kernel will check that I haven't lied to you (also called SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a syscall to query those things or both, but most Unixes also have their own unique spelling for the API, because standards are hard.[2] S [1] Strictly speaking the uid, gid and pid I had at the time I opened this socket [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and several platforms (sadly not including Linux) share getpeereid(). For the gory details see libdbus source code. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 2:59 PM, Paul Davis p...@linuxaudiosystems.com wrote: I understand the appeal of using existing technology (i.e. Wayland) to accomplish something when it appears that it will make it much easier. But if GTK is still at least nominally cross-platform, then surely the place to start is a higher level abstraction of the transport system, and then later to bolt wayland onto that design under the hood, rather than starting with Wayland and then shrugging one's hands and saying do something like Wayland on other platforms? I don't see how anything I've said could be used to imply that GTK is, nominally or concretely, not cross-platform anymore. What is being discussed here is the possibility of using Wayland as the implementation to communicate privately between the preview plugin process and the main process, without a Wayland requirement for the session the processes live in. I'm arguing that as long as the Wayland libraries can be built on the platforms we care about and a suitable way of sharing a buffer exists, even if not extremely optimized, we can possibly get away without the abstraction you're talking about. Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 10:55 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: Wayland requires two features that would perhaps make it unportable: FD passing (SCM_CREDENTIALS), and shared memory (allocate a temporary files, ftruncate it, mmap it, unlink it and then send the fd across the wire). Everything else is just a simple Unix domain socket. Does OS X support those two features? It would appear so: fd passing: http://flylib.com/books/en/3.126.1.113/1/ shared memory is supported using the POSIX shared memory API, not the system V one. I have no idea if the combination of the two (shared memory, fd passing) together works. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On 27/01/15 15:55, Jasper St. Pierre wrote: Wayland requires two features that would perhaps make it unportable: FD passing (SCM_CREDENTIALS), and shared memory (allocate a temporary files, ftruncate it, mmap it, unlink it and then send the fd across the wire). Everything else is just a simple Unix domain socket. Does OS X support those two features? I think you mean SCM_RIGHTS? SCM_RIGHTS is here's a message with an open fd attached. It's how D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite platform, Wayland fd-passing should too. SCM_CREDENTIALS is here's a message with my uid, gid and pid[1] attached, the kernel will check that I haven't lied to you (also called SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a syscall to query those things or both, but most Unixes also have their own unique spelling for the API, because standards are hard.[2] S [1] Strictly speaking the uid, gid and pid I had at the time I opened this socket [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and several platforms (sadly not including Linux) share getpeereid(). For the gory details see libdbus source code. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
