Re: [RFC] libinputmapper: Input device configuration for graphic-servers
On Fri, May 24, 2013 at 05:07:14PM +0200, David Herrmann wrote: [...] > >> This library is intended to solve the classification/detection > >> problem. While the kernel evdev-interface provides us a bunch of > >> information for each device, it doesn't provide any classification of > >> the device (mostly because it would be unreliable). So libinputmapper > >> as I see it is supposed to replace the heuristics that we currently > >> have (KEY_A-KEY_Z => keyboard, REL_X/Y => mouse, ...) with a more > >> user-controlled interface. > >> > >> So a *compositor* defines the type of devices, that it wants to > >> support. As an example, it needs mouse+touchpad devices as > >> mouse-input, keyboards as keyboard input. It then listens for all > >> input hotplug events via udev, calls libinputmapper to provide tags > >> for the devices and then checks, whether it's one of the devices that > >> it wants. Client-side support is not involved, yet. > > > > ok, that makes sense to me and is a good idea. it's a combined version of > > (formerly) udev's input_id tool and the Match* system that X has, in the > > form of a library with simple adjustment based on textfiles. > > > > good. and sorry, I did somewhat tie all this in with the client side as > > well, which is where the confusion came from. > > > > I think the tagging library will be quite private to the compositor > > implementation (even if that means all compositors). in the X case, we have > > evdev and the wacom driver for tablet devices since they're different > > enough to basic tablets. I suspect something like that > > may be required for wayland sooner or later. > > input_id+Match* seems to be a good description. That's what I had in > mind. But I don't see a reason to keep it private to the compositor. > The compositor is the #1 user of the library, but whatever API is used > to forward events to a client, we shouldn't hide this source. We can > save all other kinds of useful information in these files. A client > could retrieve device-geometry information or other static data. > I designed the configuration to allow a global database with local > additions. So a compositor can have a different configuration than a > client. But both have the same global base/fallback configuration. ok. the reason I assumed private is because you need to decide where the level of abstraction sits and I think we don't think of it the same way there. you can tag a device as tablet, but that doesn't tell you which driver to use in the compositor to parse the data (see wacom example). so now the compositor has another lookup table so it knows which module to load for this device. this lookup table can either be duplicated across compositors, or be moved into a library. and now you have your libinputmodulemapper on top (well, on the side) of libinputmapper. likewise, as in another part of this thread: the compositor may not care about the distinction between joystick/gamepad but the client may. so again we have two different use-cases and mapping requirements here. > > so the tagging library would have to tag a device not just as graphics > > tablet but more as input module selection library. which again, means it's a > > library version of input_id and Match*, etc. > > > > what you will also need then is for drivers to provide hooks to notify what > > they can deal with. i.e. libtouchpadcommon needs to install data files for > > libinputmapper to notify that it's now taking over touchpads. > > I wanted to keep this private to the compositor. So the compositor has > a list of drivers and a libinputmapper context. It then retrieves the > tags for a device and assigns the device depending on the tags to the > right driver. So libinputmapper always returns the same information. > It's up to the compositor to use this according to it's capabilities. > Or what would be the benefit of telling libinputmapper which drivers > are available? > > I also don't understand what you mean by "install data files". What > data-files would libtouchpadcommon install? once you have input modules that are externalised (which they should be to allow for re-use across compositors) you'll have to deal with the issue of _which_ modules are actually installed. so you run into the same situation as we do with X input modules: evdev handles anything, but synaptics will install a MatchIsTouchpad snippet to take over all touchpads. on top of that you have per-device quirks. the X wacom driver knows it can handle some n-trig and waltop devices, but it can't handle all tablets. so it installs MatchProduct snippets for those devices. you could handle all that in the compositor, but it can get complex once you look at more than 3+ modules and several compositors that would duplicate this. > My idea was to keep config-files generic. One file with "match"-rules > and a bunch of "device"-rules files. The match-rules would be used by > libinputmapper to find the device-rule (if any) files that should be
Re: ANNOUNCE: Wayland Live CD that starts directly to Wayland
On Sat, May 25, 2013 at 7:15 AM, Ilyes Gouta wrote:
> Hi,
>
> Would it be possible to place that ISO image on a usb key and to boot from
> it?
>
If you're using GRUB2 you can do even better. Just place the script
attached to this mail in the file /etc/grub.d/60_isoboot
Then place your ISO in the directory /boot/images/
Now just run "update-grub" and the ISO will automatically be added to the
GRUB boot menu, and you can boot from it directly from the GRUB boot menu.
> Ilyes
> On May 24, 2013 11:01 PM, "nerdopolis"
> wrote:
>
>> **
>>
>> New Wayland Live CD / First true Wayland Live CD.
>>
>>
>>
>> Hi. Today I pushed out a new ISO of my Wayland Live CD project, which is
>> named for my favorite celebrity.
>>
>>
>>
>> For this new Wayland CD, I wrote a new login manager with Bash and Zenity
>> and Expect (and Script) that fully runs on a Wayland server (weston).
>>
>>
>>
>> Now X is no longer involved in the boot process, and X does not start,
>> (unless you use an X application with xwayland), because I replaced LightDM
>> with the new loginmanager
>>
>>
>>
>> ***As far as security goes, it does store the password in the
>> environment, but the users would have to be either root or daemon in order
>> to be able to read the /proc//environ, depending on the process. It
>> also has a FIFO that has 777 access, but login info is never passed across
>> it, just commands that tell it to switch user ttys, show a login prompt,
>> show a shutdown menu, and tell the script who's weston owns a TTY. So if
>> you decide to install it, and depend on security, be warned.***
>>
>>
>>
>> And just a note for people that switch ttys. The script tries to find the
>> first available TTY automatically that isn't open, and it seems to favor
>> TTY8, and then start using the next ones for the session. (Unlike what we
>> are used to in X, where it defaults to TTY7)
>>
>>
>>
>> I got it to a point where it supports automatic login, picking a user
>> from a list to login, and switching user sessions.
>>
>> It also supports specifying the desktop environment you want to use,
>> similar to the X display managers, only for desktop environments that run
>> as plugins under Weston. Right now, all I have is Weston's
>> desktop-shell.so, but in the next ISO, I can add Weston's tablet-shell.so,
>> as well as Hawaii's Weston plugin.
>>
>>
>>
>> It even works in virtualbox if there is a framebuffer, as if there is no
>> kms, it falls back to using a framebuffer. (and if there is no framebuffer,
>> it falls back to a text dialog).
>>
>> Under virtualbox, you might have to select a different boot option to
>> force create a framebuffer.
>>
>>
>>
>> there's also a command line wizard
>>
>> rbos-add-framebuffer
>>
>> It's basically an easy to use frontline for adding vga= argument to
>> /etc/default/grub if you install the system. It does have ubiquity, it has
>> the shortcut in the Desktop folder. (or the command).
>>
>>
>>
>>
>>
>> You can download the new ISO here: (sorry, 32 bit only, as I need to work
>> my 32 bit dpkg to install a 64 bit kernel again)
>>
>>
>> http://sourceforge.net/projects/rebeccablackos/files/May%2024th%202013/RebeccaBlackLinux_i386.iso/download
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
#!/bin/sh
set -e
IMAGES=/boot/images
. /usr/lib/grub/grub-mkconfig_lib
find $IMAGES -name "*.iso" | sort |
while read image ; do
IMAGEPATH=$( make_system_path_relative_to_its_root "$image" )
echo "Found ISO image: $IMAGEPATH" >&2
#now we need to find out what the initrd file is called
INITRD="$(isoinfo -l -i "$IMAGEPATH" | egrep -o INITRD*.* | sed 's/;1 $//' | tr
'[A-Z]' '[a-z]' )"
cat << EOF
menuentry "Bootable ISO: $(basename $IMAGEPATH | sed s/.iso//)" {
loopback loop $image
set gfxpayload=keep
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$image noeject
noprompt --
initrd (loop)/casper/$INITRD
}
EOF
done
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: ANNOUNCE: Wayland Live CD that starts directly to Wayland
Hi, On Mon, May 27, 2013 at 12:57 PM, Rune Kjær Svendsen wrote: > On Sat, May 25, 2013 at 7:15 AM, Ilyes Gouta wrote: > >> Hi, >> >> Would it be possible to place that ISO image on a usb key and to boot >> from it? >> > If you're using GRUB2 you can do even better. Just place the script > attached to this mail in the file /etc/grub.d/60_isoboot > > Then place your ISO in the directory /boot/images/ > > Now just run "update-grub" and the ISO will automatically be added to the > GRUB boot menu, and you can boot from it directly from the GRUB boot menu. > Cool! Thanks for the tip. I got the image running on my laptop which has a radeon r600 GPU, and it was all smooth, snappy and functional. Yet I think the Qt integration still needs a bit of work, especially with window resizing and widgets placement. Chrome ran correctly and I do remember it crashed when opening YouTube. nerdopolis, you could make it even more interesting by building the entire stack w/ debug symbols and providing a way to testers to report crashes and gdb core dumps, etc. Ilyes On May 24, 2013 11:01 PM, "nerdopolis" >> wrote: >> >>> ** >>> >>> New Wayland Live CD / First true Wayland Live CD. >>> >>> >>> >>> Hi. Today I pushed out a new ISO of my Wayland Live CD project, which is >>> named for my favorite celebrity. >>> >>> >>> >>> For this new Wayland CD, I wrote a new login manager with Bash and >>> Zenity and Expect (and Script) that fully runs on a Wayland server >>> (weston). >>> >>> >>> >>> Now X is no longer involved in the boot process, and X does not start, >>> (unless you use an X application with xwayland), because I replaced LightDM >>> with the new loginmanager >>> >>> >>> >>> ***As far as security goes, it does store the password in the >>> environment, but the users would have to be either root or daemon in order >>> to be able to read the /proc//environ, depending on the process. It >>> also has a FIFO that has 777 access, but login info is never passed across >>> it, just commands that tell it to switch user ttys, show a login prompt, >>> show a shutdown menu, and tell the script who's weston owns a TTY. So if >>> you decide to install it, and depend on security, be warned.*** >>> >>> >>> >>> And just a note for people that switch ttys. The script tries to find >>> the first available TTY automatically that isn't open, and it seems to >>> favor TTY8, and then start using the next ones for the session. (Unlike >>> what we are used to in X, where it defaults to TTY7) >>> >>> >>> >>> I got it to a point where it supports automatic login, picking a user >>> from a list to login, and switching user sessions. >>> >>> It also supports specifying the desktop environment you want to use, >>> similar to the X display managers, only for desktop environments that run >>> as plugins under Weston. Right now, all I have is Weston's >>> desktop-shell.so, but in the next ISO, I can add Weston's tablet-shell.so, >>> as well as Hawaii's Weston plugin. >>> >>> >>> >>> It even works in virtualbox if there is a framebuffer, as if there is no >>> kms, it falls back to using a framebuffer. (and if there is no framebuffer, >>> it falls back to a text dialog). >>> >>> Under virtualbox, you might have to select a different boot option to >>> force create a framebuffer. >>> >>> >>> >>> there's also a command line wizard >>> >>> rbos-add-framebuffer >>> >>> It's basically an easy to use frontline for adding vga= argument to >>> /etc/default/grub if you install the system. It does have ubiquity, it has >>> the shortcut in the Desktop folder. (or the command). >>> >>> >>> >>> >>> >>> You can download the new ISO here: (sorry, 32 bit only, as I need to >>> work my 32 bit dpkg to install a 64 bit kernel again) >>> >>> >>> http://sourceforge.net/projects/rebeccablackos/files/May%2024th%202013/RebeccaBlackLinux_i386.iso/download >>> >>> ___ >>> wayland-devel mailing list >>> wayland-devel@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >>> >>> >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> >> > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] config-parser: Avoid null dereference when handling config-parser ( when weston starts without config file. )
This patch fixes segmentation fault when weston starts without config file.
---
>From ad383a1ed8efa3ee402825bb99676c22f6578a5c Mon Sep 17 00:00:00 2001
From: Mun Gwan-gyeong
Date: Tue, 28 May 2013 00:04:26 +0900
Subject: [PATCH] config-parser: Avoid null dereference when handling
config-parser ( when weston starts without config file. )
backtrace:
(gdb) bt
#0 weston_config_next_section (config=0x0, section=0xbfb2b608,
name=0xbfb2b618) at config-parser.c:485
#1 0xb75b1371 in x11_compositor_create (config=0x1, argv=0xbfb2ba44,
argc=, use_pixman=0, no_input=0, fullscreen=0,
display=0xb75b55f9)
at compositor-x11.c:1582
#2 backend_init (display=0x8354490, argc=0xbfb2b9b0, argv=0xbfb2ba44,
config=0x0) at compositor-x11.c:1674
#3 0x0804df7b in main (argc=1, argv=0xbfb2ba44) at compositor.c:3289
---
shared/config-parser.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/shared/config-parser.c b/shared/config-parser.c
index 7a19ea5..eec3e9e 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -481,6 +481,9 @@ weston_config_next_section(struct weston_config *config,
struct weston_config_section **section,
const char **name)
{
+ if (config == NULL)
+ return 0;
+
if (*section == NULL)
*section = container_of(config->section_list.next,
struct weston_config_section, link);
--
1.7.9.5
>From ad383a1ed8efa3ee402825bb99676c22f6578a5c Mon Sep 17 00:00:00 2001
From: Mun Gwan-gyeong
Date: Tue, 28 May 2013 00:04:26 +0900
Subject: [PATCH] config-parser: Avoid null dereference when handling
config-parser ( when weston starts without config file. )
backtrace:
(gdb) bt
#0 weston_config_next_section (config=0x0, section=0xbfb2b608, name=0xbfb2b618) at config-parser.c:485
#1 0xb75b1371 in x11_compositor_create (config=0x1, argv=0xbfb2ba44, argc=, use_pixman=0, no_input=0, fullscreen=0, display=0xb75b55f9)
at compositor-x11.c:1582
#2 backend_init (display=0x8354490, argc=0xbfb2b9b0, argv=0xbfb2ba44, config=0x0) at compositor-x11.c:1674
#3 0x0804df7b in main (argc=1, argv=0xbfb2ba44) at compositor.c:3289
---
shared/config-parser.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/shared/config-parser.c b/shared/config-parser.c
index 7a19ea5..eec3e9e 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -481,6 +481,9 @@ weston_config_next_section(struct weston_config *config,
struct weston_config_section **section,
const char **name)
{
+ if (config == NULL)
+ return 0;
+
if (*section == NULL)
*section = container_of(config->section_list.next,
struct weston_config_section, link);
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] config-parser: Avoid null dereference when exiting. (case: weston starts without config file)
When exiting, this patch fixes segmentation fault.
---
From: Mun Gwan-gyeong
Date: Tue, 28 May 2013 00:20:04 +0900
Subject: [PATCH] config-parser: Avoid null dereference when exiting. (case:
weston starts without config file.)
backtrace:
(gdb) bt
#0 0xb7704424 in __kernel_vsyscall ()
#1 0xb757ddde in raise (sig=5) at
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
#2
#3 weston_config_destroy (config=0x0) at config-parser.c:508
#4 0xb75cbc0e in x11_destroy (ec=0x93506b0) at compositor-x11.c:1473
#5 0x0804e0e9 in main (argc=1, argv=0xbffe5354) at compositor.c:3337
---
shared/config-parser.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/shared/config-parser.c b/shared/config-parser.c
index eec3e9e..1d88eed 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -505,6 +505,9 @@ weston_config_destroy(struct weston_config *config)
struct weston_config_section *s, *next_s;
struct weston_config_entry *e, *next_e;
+ if (config == NULL)
+ return;
+
wl_list_for_each_safe(s, next_s, &config->section_list, link) {
wl_list_for_each_safe(e, next_e, &s->entry_list, link) {
free(e->key);
--
1.7.9.5
>From 8543b9138b57f7b96d2137fef78b03d13ca0f412 Mon Sep 17 00:00:00 2001
From: Mun Gwan-gyeong
Date: Tue, 28 May 2013 00:20:04 +0900
Subject: [PATCH] config-parser: Avoid null dereference when exiting. (case:
weston starts without config file.)
backtrace:
(gdb) bt
#0 0xb7704424 in __kernel_vsyscall ()
#1 0xb757ddde in raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
#2
#3 weston_config_destroy (config=0x0) at config-parser.c:508
#4 0xb75cbc0e in x11_destroy (ec=0x93506b0) at compositor-x11.c:1473
#5 0x0804e0e9 in main (argc=1, argv=0xbffe5354) at compositor.c:3337
---
shared/config-parser.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/shared/config-parser.c b/shared/config-parser.c
index eec3e9e..1d88eed 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -505,6 +505,9 @@ weston_config_destroy(struct weston_config *config)
struct weston_config_section *s, *next_s;
struct weston_config_entry *e, *next_e;
+ if (config == NULL)
+ return;
+
wl_list_for_each_safe(s, next_s, &config->section_list, link) {
wl_list_for_each_safe(e, next_e, &s->entry_list, link) {
free(e->key);
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] libinputmapper: Input device configuration for graphic-servers
Hi Peter On Mon, May 27, 2013 at 12:35 PM, Peter Hutterer wrote: > On Fri, May 24, 2013 at 05:07:14PM +0200, David Herrmann wrote: > [...] >> >> This library is intended to solve the classification/detection >> >> problem. While the kernel evdev-interface provides us a bunch of >> >> information for each device, it doesn't provide any classification of >> >> the device (mostly because it would be unreliable). So libinputmapper >> >> as I see it is supposed to replace the heuristics that we currently >> >> have (KEY_A-KEY_Z => keyboard, REL_X/Y => mouse, ...) with a more >> >> user-controlled interface. >> >> >> >> So a *compositor* defines the type of devices, that it wants to >> >> support. As an example, it needs mouse+touchpad devices as >> >> mouse-input, keyboards as keyboard input. It then listens for all >> >> input hotplug events via udev, calls libinputmapper to provide tags >> >> for the devices and then checks, whether it's one of the devices that >> >> it wants. Client-side support is not involved, yet. >> > >> > ok, that makes sense to me and is a good idea. it's a combined version of >> > (formerly) udev's input_id tool and the Match* system that X has, in the >> > form of a library with simple adjustment based on textfiles. >> > >> > good. and sorry, I did somewhat tie all this in with the client side as >> > well, which is where the confusion came from. >> > >> > I think the tagging library will be quite private to the compositor >> > implementation (even if that means all compositors). in the X case, we have >> > evdev and the wacom driver for tablet devices since they're different >> > enough to basic tablets. I suspect something like that >> > may be required for wayland sooner or later. >> >> input_id+Match* seems to be a good description. That's what I had in >> mind. But I don't see a reason to keep it private to the compositor. >> The compositor is the #1 user of the library, but whatever API is used >> to forward events to a client, we shouldn't hide this source. We can >> save all other kinds of useful information in these files. A client >> could retrieve device-geometry information or other static data. >> I designed the configuration to allow a global database with local >> additions. So a compositor can have a different configuration than a >> client. But both have the same global base/fallback configuration. > > ok. the reason I assumed private is because you need to decide where the > level of abstraction sits and I think we don't think of it the same way > there. > > you can tag a device as tablet, but that doesn't tell you which driver to > use in the compositor to parse the data (see wacom example). so now the > compositor has another lookup table so it knows which module to load for > this device. this lookup table can either be duplicated across compositors, > or be moved into a library. and now you have your libinputmodulemapper on > top (well, on the side) of libinputmapper. I don't understand. What's wrong with linking device-TAGs to drivers in the compositor? So the compositor loads all drivers dynamically and each driver specifies which tags it supports. A new device is then assigned to the driver that currently is associated with the tag. If you want to overwrite that, add a "[driver]" section to the device-config/rule and use "bind = ". The compositor then needs to support the "[driver]" section and can see whether it should force-bind another driver than the default. Or even better, if you have multiple tags for tablets, like TAG_TABLET and TAG_WACOM_TABLET, you can define both on wacom tablets but only TAG_TABLET on other random tablets. Then bind the normal tablet/mouse/whatever driver to TAG_TABLET and your wacom driver to TAG_WACOM_TABLET. Of course, TAG_WACOM_TABLET then needs a higher priority than TAG_TABLET. This will work whether the wacom-driver is loaded or not. > likewise, as in another part of this thread: the compositor may not care > about the distinction between joystick/gamepad but the client may. so again > we have two different use-cases and mapping requirements here. Then the compositor just binds it's gaming-device-driver to (TAG_JOYSTICK | TAG_GAMEPAD). A client may use TAG_JOYSTICK or TAG_GAMEPAD separately. I don't see the problem here? >> > so the tagging library would have to tag a device not just as graphics >> > tablet but more as input module selection library. which again, means it's >> > a >> > library version of input_id and Match*, etc. >> > >> > what you will also need then is for drivers to provide hooks to notify what >> > they can deal with. i.e. libtouchpadcommon needs to install data files for >> > libinputmapper to notify that it's now taking over touchpads. >> >> I wanted to keep this private to the compositor. So the compositor has >> a list of drivers and a libinputmapper context. It then retrieves the >> tags for a device and assigns the device depending on the tags to the >> right driver. So libinputmapper alw
[PATCH] Fix name clash in RDP compositor
This patch fixes some name clashes introduced by last patches.
---
src/compositor-rdp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index 1711fdd..e855ba6 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -965,7 +965,7 @@ rdp_incoming_peer(freerdp_listener *instance, freerdp_peer
*client)
static struct weston_compositor *
rdp_compositor_create(struct wl_display *display,
struct rdp_compositor_config *config,
- int *argc, char *argv[], struct weston_config *config)
+ int *argc, char *argv[], struct weston_config *wconfig)
{
struct rdp_compositor *c;
char *fd_str;
@@ -977,7 +977,7 @@ rdp_compositor_create(struct wl_display *display,
memset(c, 0, sizeof *c);
- if (weston_compositor_init(&c->base, display, argc, argv, config) < 0)
+ if (weston_compositor_init(&c->base, display, argc, argv, wconfig) < 0)
goto err_free;
c->base.destroy = rdp_destroy;
@@ -1046,7 +1046,7 @@ err_free:
WL_EXPORT struct weston_compositor *
backend_init(struct wl_display *display, int *argc, char *argv[],
-struct weston_config *config)
+struct weston_config *wconfig)
{
struct rdp_compositor_config config;
rdp_compositor_config_init(&config);
@@ -1069,5 +1069,5 @@ backend_init(struct wl_display *display, int *argc, char
*argv[],
};
parse_options(rdp_options, ARRAY_LENGTH(rdp_options), argc, argv);
- return rdp_compositor_create(display, &config, argc, argv, config);
+ return rdp_compositor_create(display, &config, argc, argv, wconfig);
}
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
