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 applied to the device. The device-rules contain different sections. libinputmapper only parses one section
Re: ANNOUNCE: Wayland Live CD that starts directly to Wayland
On Sat, May 25, 2013 at 7:15 AM, Ilyes Gouta ilyes.go...@gmail.com 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 bluescreen_aven...@verizon.net
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/pid/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
[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 elong...@gmail.com
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=optimized out, 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 elong...@gmail.com
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=optimized out, 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 elong...@gmail.com
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 signal handler called
#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 elong...@gmail.com
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 signal handler called
#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 peter.hutte...@who-t.net 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 = some-driver-name. 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 always returns the same information. It's up to the compositor to use this according to it's capabilities. Or what would be the
[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
