[PATCH synaptics] Don't check for soft buttons if a button is already down

2012-05-09 Thread Peter Hutterer 
Moving into a different soft button's area during drag-n-drop would trigger
a click of that button.

http://bugzilla.redhat.com/819348

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
 src/synaptics.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/synaptics.c b/src/synaptics.c
index 7881926..e47d8ff 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -2539,7 +2539,7 @@ update_hw_button_state(const InputInfoPtr pInfo, struct 
SynapticsHwState *hw,
 
 /* If this is a clickpad and the user clicks in a soft button area, press
  * the soft button instead. */
-if (para-clickpad  hw-left  !hw-right  !hw-middle) {
+if (para-clickpad  hw-left  !hw-right  !hw-middle  !old-left) 
{
 if (is_inside_rightbutton_area(para, hw-x, hw-y)) {
 hw-left = 0;
 hw-right = 1;
-- 
1.7.10.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH synaptics] Fix coasting speed trigger

2012-05-09 Thread Peter Hutterer 
CoastingSpeed is defined as scrolls/s. The previous code just used
delta/seconds which depended on the device coordinate range and exceeded the
default CoastingSpeed at almost any scroll event.

Divide the estimated delta by the scroll distance to get the accurate
scrolls/s number. Since that now changes the contents of what's in
coast_speed_y, change the users of that too.

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
This changes the coasting behaviour to finish a lot quicker with the default
options. Which, iirc, was the behaviour in 1.4 or 1.5 anyway. 1.6 coasts a
bit too long though no idea what exact set of commits introduced that
regression to begin with.

 src/synaptics.c|   16 +++-
 src/synapticsstr.h |6 +++---
 2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/src/synaptics.c b/src/synaptics.c
index e47d8ff..e95c0fc 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -2109,7 +2109,7 @@ start_coasting(SynapticsPrivate * priv, struct 
SynapticsHwState *hw,
 double dy =
 estimate_delta(HIST(0).y, HIST(1).y, HIST(2).y, HIST(3).y);
 if (pkt_time  0) {
-double scrolls_per_sec = dy / pkt_time;
+double scrolls_per_sec = (dy / abs(para-scroll_dist_vert)) / 
pkt_time;
 
 if (fabs(scrolls_per_sec) = para-coasting_speed) {
 priv-scroll.coast_speed_y = scrolls_per_sec;
@@ -2121,7 +2121,7 @@ start_coasting(SynapticsPrivate * priv, struct 
SynapticsHwState *hw,
 double dx =
 estimate_delta(HIST(0).x, HIST(1).x, HIST(2).x, HIST(3).x);
 if (pkt_time  0) {
-double scrolls_per_sec = dx / pkt_time;
+double scrolls_per_sec = (dx / abs(para-scroll_dist_vert)) / 
pkt_time;
 
 if (fabs(scrolls_per_sec) = para-coasting_speed) {
 priv-scroll.coast_speed_x = scrolls_per_sec;
@@ -2133,7 +2133,7 @@ start_coasting(SynapticsPrivate * priv, struct 
SynapticsHwState *hw,
 double da = estimate_delta_circ(priv);
 
 if (pkt_time  0) {
-double scrolls_per_sec = da / pkt_time;
+double scrolls_per_sec = (da / para-scroll_dist_circ) / 
pkt_time;
 
 if (fabs(scrolls_per_sec) = para-coasting_speed) {
 if (vert) {
@@ -2391,10 +2391,9 @@ HandleScrolling(SynapticsPrivate * priv, struct 
SynapticsHwState *hw,
 
 if (priv-scroll.coast_speed_y) {
 double dtime = (hw-millis - priv-scroll.last_millis) / 1000.0;
-double ddy =
-para-coasting_friction * dtime * abs(para-scroll_dist_vert);
+double ddy = para-coasting_friction * dtime;
 
-priv-scroll.delta_y += priv-scroll.coast_speed_y * dtime;
+priv-scroll.delta_y += priv-scroll.coast_speed_y * dtime * 
para-scroll_dist_vert;
 delay = MIN(delay, POLL_MS);
 if (abs(priv-scroll.coast_speed_y)  ddy) {
 priv-scroll.coast_speed_y = 0;
@@ -2408,9 +2407,8 @@ HandleScrolling(SynapticsPrivate * priv, struct 
SynapticsHwState *hw,
 
 if (priv-scroll.coast_speed_x) {
 double dtime = (hw-millis - priv-scroll.last_millis) / 1000.0;
-double ddx =
-para-coasting_friction * dtime * abs(para-scroll_dist_horiz);
-priv-scroll.delta_x += priv-scroll.coast_speed_x * dtime;
+double ddx = para-coasting_friction * dtime;
+priv-scroll.delta_x += priv-scroll.coast_speed_x * dtime * 
para-scroll_dist_vert;
 delay = MIN(delay, POLL_MS);
 if (abs(priv-scroll.coast_speed_x)  ddx) {
 priv-scroll.coast_speed_x = 0;
diff --git a/src/synapticsstr.h b/src/synapticsstr.h
index 4bc2ed5..5b0120a 100644
--- a/src/synapticsstr.h
+++ b/src/synapticsstr.h
@@ -169,7 +169,7 @@ typedef struct _SynapticsParameters {
 Bool palm_detect;   /* Enable Palm Detection */
 int palm_min_width; /* Palm detection width */
 int palm_min_z; /* Palm detection depth */
-double coasting_speed;  /* Coasting threshold scrolling speed */
+double coasting_speed;  /* Coasting threshold scrolling speed in 
scrolls/s */
 double coasting_friction;   /* Number of scrolls per second per second to 
change coasting speed */
 int press_motion_min_z; /* finger pressure at which minimum pressure 
motion factor is applied */
 int press_motion_max_z; /* finger pressure at which maximum pressure 
motion factor is applied */
@@ -213,8 +213,8 @@ struct _SynapticsPrivateRec {
 double delta_y; /* accumulated vert scroll delta */
 double last_a;  /* last angle-scroll position */
 CARD32 last_millis; /* time last scroll event posted */
-double coast_speed_x;   /* Horizontal coasting speed */
-double coast_speed_y;   /* Vertical coasting speed */
+double coast_speed_x;   /* Horizontal coasting speed in scrolls/s */
+

Re: [PATCH synaptics 0/3] synaptics indentation

2012-05-09 Thread Peter Hutterer 
On Wed, May 09, 2012 at 12:18:09PM +1000, Peter Hutterer wrote:
 This has always annoyed me anyway and now that we managed to get the server
 done we might as well do synaptics. Same indentation style.

Patch 1/3 is too big for the list, I've uploaded it here. It's just a run of
the x-indent-all.sh script over the synaptics tree anyways.

http://people.freedesktop.org/~whot/patches/0001-Indent-consistently.patch

Cheers,
  Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 2/2] xfree86: use udev to provide device enumeration for kms devices

2012-05-09 Thread Dave Airlie 

 Well the problem is I've no idea what hotplug on any other OS is going
 to look like,
 and I really don't want to invent an abstraction without input from
 either someone

 a) who cares about another OS
 b) has time to help me now, not in 6 months.


 Well, okay, but there's two things here.  You have config/udev growing the
 ability to plug output devices, and you have hw/xfree86 growing a new device
 enumeration method during initial config.  You're not _actually_ addressing
 hotplug yet, you've gotten as far as coldplug.

Well this code is for addressing hotplug eventually, the code is all
written to do it,
just doesn't make sense until I finish lots of other bits. The thing
is if I don't know
what the OS-specific info that needs to go from udev-driver via the xf86 DDX,
I can't abstract it. For input we've all but just made this
information udev/evdev and Linux
info, with no guarantee that other OSes could use it. So maybe I can
just pretend I'm being
OS friendly and remove the name udev.


 We'd of course need better naming for BUS_UDEV then?


 I was thinking BUS_PLATFORM.  Blue.  No, yellow.

Yeah I could live with that.


 The only non-Linux non-PCI driver I know of is wsfb.  But there's still
 dummy (and maybe nested?), and there's still fbdev, and I guess I don't have
 a good idea of how to express those.  Hmm.  Probably until I do I can't
 lobby for dropping the pre-pciaccess probe yet.  Withdrawn.

Yeah virtual drivers need old-skool probe.

 So the plan is to have two sets of xf86Screens, and if a driver
 support hotplug (it tells the server via a driverfunc call)
 you pass it a flag saying it should add a hotplug screen not a
 toplevel protocol screen.


 Is that just an optimization or is there a semantic difference?  Phrased
 another way, why are not all screens hotplug screens?  Is it just ease of
 migrating the drivers?

Ease of migrating the drivers is probably top of the list,
pointless-ness of doing hotplug on
non-KMS drivers. I don't mind doing simple automatic API tweaks in
drivers, but I'm not
really wanting to do in depth surgery in order to support hotplug on
the 5 or drivers I care about.

The current v3 plan is to have one ScreenRec/ScrnInfoRec per protocol
screen, with linkages
to one ScreenRec/ScrnInfoRec per hotplugable driver. These structures
for now would remain
the same as otherwise I don't think it'll ever get merged. So we
continue to have screenInfo.screens
and xf86Screens containing arrays of the protocol screens. Then
screenInfo.gpuscreens and
xf86GPUScreens arrays containing the hotpluggable screens.

If a driver doesn't support hotplug then it acts like it does now, we
have one ScreenRec
protocol/gpu combined screen. If a driver supports hotplug then we
create one protocol ScreenRec
and one GPU ScreenRec. If someone plugs in a device and the main
driver is a single
ScreenRec nothing happens, if someone plugs in a device and the main
driver is hotplug
capable we'll create another GPU screen rec and attach it in the
correct place, depending
on what type of slave it its initially, and once shatter works better,
it can be its own rendering
master.

 Well it could pick up headless things, but the drivers should deal
 with that in their probe code and fall out. If we ever get to adding
 render nodes we'd have to match on those as well at some point.


 Yeah, looks like nothing's calling drm_get_minor() that way yet.  I guess my
 preference was to _not_ bind to render-only nodes at this level, and start
 doing that as an EGL-level decision even under X.

But we need to bind to headless devices for PRIME to work on GPUs with
no outputs.


 No USB support?


 I don't think the concept of Primary device applies to a USB connected
 device,
 since we generally use it for insane things like int10 and stuff.


 Ah yeah, forgot that context.

 But come to that, we could just as well assert that BUS_ODEV simply requires
 that the OS have handled POSTing, and not have the notion of Primary
 defined at all.

Primary is also used on the switchable GPU laptops to denote who is running
the show, like whether Intel should be running the show with nouveau
as an offload slave
or nouveau running the show with intel as an output slave.


 Heh.  To me that sounds like incentive.  I have an almost reasonable idea of
 how that code works, I just hate it.

Some bits of xf86pciBus.c seem like stuff I'd rather not know,
MatchPciInstances is the
main, seems like a lot of code for whatever its doing.

 There is no way to enumerate non-PCI video devices without a list of
 them, KMS drivers is the only way to make it all work.

 I'm leaving the old probing functions intact for non-Linux and binary
 drivers for now, but I could be tempted to rip them out
 on Linux, if I added PCI graphics device to the udev probing I suppose.


 Well, binary drivers are going to involve a kernel driver.  Maybe it makes
 sense to think about this as ask udev about kernel graphics services
 instead of ask udev about

[PATCH] xfree86: use udev to provide device enumeration for kms devices (v2)

2012-05-09 Thread Dave Airlie 
From: Dave Airlie airl...@redhat.com

On Linux in order for future hotplug work, we are required to interface
to udev to detect device creation/removal. In order to try and get
some earlier testing on this, this patch adds the ability to use
udev for device enumeration on Linux.

At startup the list of drm/kms devices is probed and this info is
used to load drivers.

A new driver probing method is introduced that passes the udev
device info to the driver for probing.

The probing integrates with the pci probing code and will fallback
to the pci probe and old school probe functions in turn.

The flags parameter to the probe function will be used later
to provide hotplug and gpu screen flags for the driver to behave
in a different way.

This patch changes the driver ABI, all drivers should at least
be set with a NULL udev probe function after this commit.

v2: rename to platform bus, now with 100% less udev specific,

this version passes config_odev_attribs around which are an array
of id/string pairs, then the udev code can attach the set of attribs
it understands, the OS specific code can attach its attrib, and then
the core/drivers can lookup the required attribs.

also add MATCH_PCI_DEVICES macro.

This version is mainly to address concerns raised by ajax.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 config/config-backends.h |1 +
 config/config.c  |8 +
 config/udev.c|   49 +
 configure.ac |   20 ++-
 hw/xfree86/common/Makefile.am|8 +-
 hw/xfree86/common/xf86.h |5 +
 hw/xfree86/common/xf86Bus.c  |   25 ++-
 hw/xfree86/common/xf86Bus.h  |1 +
 hw/xfree86/common/xf86fbBus.c|4 +
 hw/xfree86/common/xf86pciBus.c   |   17 ++-
 hw/xfree86/common/xf86pciBus.h   |5 +
 hw/xfree86/common/xf86platformBus.c  |  264 ++
 hw/xfree86/common/xf86platformBus.h  |   52 +
 hw/xfree86/common/xf86str.h  |   15 ++
 hw/xfree86/os-support/linux/Makefile.am  |2 +-
 hw/xfree86/os-support/linux/lnx_platform.c   |   87 +
 hw/xfree86/os-support/shared/platform_noop.c |   17 ++
 hw/xfree86/os-support/xf86_OSproc.h  |6 +
 include/dix-config.h.in  |3 +
 include/hotplug.h|   16 ++
 include/xorg-config.h.in |3 +
 include/xorg-server.h.in |3 +
 22 files changed, 599 insertions(+), 12 deletions(-)
 create mode 100644 hw/xfree86/common/xf86platformBus.c
 create mode 100644 hw/xfree86/common/xf86platformBus.h
 create mode 100644 hw/xfree86/os-support/linux/lnx_platform.c
 create mode 100644 hw/xfree86/os-support/shared/platform_noop.c

diff --git a/config/config-backends.h b/config/config-backends.h
index 62abc0a..6423701 100644
--- a/config/config-backends.h
+++ b/config/config-backends.h
@@ -36,6 +36,7 @@ BOOL device_is_duplicate(const char *config_info);
 int config_udev_pre_init(void);
 int config_udev_init(void);
 void config_udev_fini(void);
+void config_udev_odev_probe(config_odev_probe_proc_ptr probe_callback);
 #else
 
 #ifdef CONFIG_NEED_DBUS
diff --git a/config/config.c b/config/config.c
index 24e7ba7..07e920e 100644
--- a/config/config.c
+++ b/config/config.c
@@ -85,6 +85,14 @@ config_fini(void)
 #endif
 }
 
+void
+config_odev_probe(config_odev_probe_proc_ptr probe_callback)
+{
+#if defined(CONFIG_UDEV_KMS)
+config_udev_odev_probe(probe_callback);
+#endif
+}
+
 static void
 remove_device(const char *backend, DeviceIntPtr dev)
 {
diff --git a/config/udev.c b/config/udev.c
index 1995184..a2d5aad 100644
--- a/config/udev.c
+++ b/config/udev.c
@@ -366,3 +366,52 @@ config_udev_fini(void)
 udev_monitor = NULL;
 udev_unref(udev);
 }
+
+#ifdef CONFIG_UDEV_KMS
+void
+config_udev_odev_probe(config_odev_probe_proc_ptr probe_callback)
+{
+struct udev *udev;
+struct udev_enumerate *enumerate;
+struct udev_list_entry *devices, *device;
+struct config_odev_attribute attribs[3];
+
+udev = udev_monitor_get_udev(udev_monitor);
+enumerate = udev_enumerate_new(udev);
+if (!enumerate)
+return;
+
+udev_enumerate_add_match_subsystem(enumerate, drm);
+udev_enumerate_add_match_sysname(enumerate, card[0-9]*);
+udev_enumerate_scan_devices(enumerate);
+devices = udev_enumerate_get_list_entry(enumerate);
+udev_list_entry_foreach(device, devices) {
+const char *syspath = udev_list_entry_get_name(device);
+struct udev_device *udev_device = udev_device_new_from_syspath(udev, 
syspath);
+const char *path = udev_device_get_devnode(udev_device);
+const char *sysname = udev_device_get_sysname(udev_device);
+int probe = TRUE;
+
+if (!path || !syspath)
+probe = FALSE;
+   if

Re: [PULL libxkbcommon] Some more fixes and minor enhancements

2012-05-09 Thread Ran Benita 
On Tue, May 08, 2012 at 05:35:23PM +0100, Daniel Stone wrote:
 Hi Ran,
 Sorry for the delay, have been sidetracked by core Wayland stuff for a bit.

Hi!

 Thanks a bunch for all your last changes too, I've merged everything
 except the DFLT_XKB_CONFIG_ROOT change and the Unicode tests.  Again
 for the Unicode tests I want to use UTF-8 rather than UCS-4 and will
 get to this really quite soon now I promise (finally have some time to
 poke back at xkbcommon).

Yes, but I think having UCS-4 makes sense as well, by which I mean that
are applications (mine..) which have good reasons to use it. Since the
existing implemantations (the libX11 one and the Markus Kuhn one)
convert to uint32_t anyway, why not expose it in addition to UTF-8? So
when you implement it please have a UCS-4 one :)

 As for the DFLT_XKB_CONFIG_ROOT change, it's ugly as sin but
 unfortunately it's the only way for it to work properly, since just
 substituting from within configure doesn't always perform enough
 expansion.  On some versions you'll be left with the string being
 ${datarootdir}/share/X11/xkb or similar.  The 'fix' there is to just
 do more rounds of expansion, but the upstream-recommended method is
 actually to do it as we're doing it now, believe it or not.
 
 autotools makes me sad sometimes.

Didn't know that; good that you caught it.

 As for the rest -
 
 On 11 April 2012 19:58, Ran Benita ran...@gmail.com wrote:
  On Mon, Apr 02, 2012 at 12:04:25PM +0100, Daniel Stone wrote:
  Right, so allow it to call through arbitrary function pointers? I was
  considering doing that, but wasn't particularly feeling like dealing
  with the intracacies of varargs again that day.
 
  Varags aren't so bad. I had some fun abusing them here:
  https://github.com/bluetech/libxkbcommon/blob/tests2/test/keyseq.c
  That said, you can look at the libabc example code, if you think that's
  a better approach.
 
 Yeah, the tests look really good and we should definitely be doing
 that, I'm going to merge in a really minimal dataset too so we're not
 relying on an installed dataset for all our tests.  At that point we
 can go all-out and throw in a lot more tests for esoteric stuff like
 locking modifiers.
 
 I don't know if I'll have too much time to poke at the log stuff
 anytime soon, but it definitely sounds good.
 
  I'd like to be able to support full dumps (e.g. generated from xkbcomp
  -xkb :0 foo.txt) being loaded in to xkbcommon without triggering
  parsing errors because it doesn't have natural support for floats.
  That was the best way I found to do that; is there something I'm
  missing?
 
  Hmm, if I get it right, floats etc, can only appear inside xkb_geometry
  sections (which we treat as files). So the scanner should be able to lex
  them, but the parser can just skip the section and not have to know
  anything inside it. I'm not sure yacc does that off hand, I'll try it.
  Of course, it may be worth keeping for completeness or whatever.
 
 Hmm.  If it works then it'd definitely be a net win. :)

Of course I didn't take a compiler class yet and so I hadn't realized
yacc does bottom-up parsing, making this impossible... (at least in a
straightforward way)

  Another question than :) We currently support three types of aggregate
  files, which are xkb_keymap, xkb_layout and xkb_semantics. The keymap
  can include all components (i.e. keycodes, symbols...), and the other
  two only one or two (mandatory / optional - see XKBcommonint.h
  #defines). Looking in /usr/share/X11/xkb, the layout type is completely
  unused, and there are a couple semantics files (which seem unused). So,
  is it worth keeping those? I don't think they serve any useful purpose?
  (unless someone tries to load them, but I don't think anyone has them
  lying around).
 
 No, we can jettison the other two.  In theory we need them for
 compatibility, but in reality they don't exist and I don't care.

I have done this now. I've kept backward compatibility by just treating
them as xkb_keymap in the parser. See the branch below.

  And lastly (I promise :), I'm thinking about a situation where there are
  several users of the library (say xserver, wayland/weston, kmscon,
  toolkits) and they all load a keymap from an rmlvo. Currently it seems
  like the end user would have to configure her preferred rmlvo separately
  for each one, which can get annoying (already..). Since you mentioned
  loading files from ~/.xkb/, would it make sense to support some simple
  config file for that? That way if the end user didn't explicitly
  override through the application, and the config file exists, it should
  be used as the default instead of some us layout.
 
  And if it makes sense, should libxkbcommon be the one doing it anyway?
 
 Yeah, I think we should have a global file and a per-user override
 too.  I'd like to see the following be possible:
 * xkbrc (or something): set the default names, which would allow
 us to pass NULL to the compilation functions and get the

Re: [PULL libxkbcommon] Some more fixes and minor enhancements

2012-05-09 Thread Kristian Høgsberg 
Hi Ran,

Let me just point you to this branch as well:

  http://cgit.freedesktop.org/~krh/libxkbcommon/log/?h=keysyms

I've been talking with Daniel about this in IRC, but I thought you
might want to take a look too.  With those patches the API is
completely self-contained.  We still need xproto, kbproto and
Xfuncproto at compile time, but none of that leaks through the
exported API.

Krisitian

On Wed, May 9, 2012 at 11:13 AM, Ran Benita ran...@gmail.com wrote:
 On Tue, May 08, 2012 at 05:35:23PM +0100, Daniel Stone wrote:
 Hi Ran,
 Sorry for the delay, have been sidetracked by core Wayland stuff for a bit.

 Hi!

 Thanks a bunch for all your last changes too, I've merged everything
 except the DFLT_XKB_CONFIG_ROOT change and the Unicode tests.  Again
 for the Unicode tests I want to use UTF-8 rather than UCS-4 and will
 get to this really quite soon now I promise (finally have some time to
 poke back at xkbcommon).

 Yes, but I think having UCS-4 makes sense as well, by which I mean that
 are applications (mine..) which have good reasons to use it. Since the
 existing implemantations (the libX11 one and the Markus Kuhn one)
 convert to uint32_t anyway, why not expose it in addition to UTF-8? So
 when you implement it please have a UCS-4 one :)

 As for the DFLT_XKB_CONFIG_ROOT change, it's ugly as sin but
 unfortunately it's the only way for it to work properly, since just
 substituting from within configure doesn't always perform enough
 expansion.  On some versions you'll be left with the string being
 ${datarootdir}/share/X11/xkb or similar.  The 'fix' there is to just
 do more rounds of expansion, but the upstream-recommended method is
 actually to do it as we're doing it now, believe it or not.

 autotools makes me sad sometimes.

 Didn't know that; good that you caught it.

 As for the rest -

 On 11 April 2012 19:58, Ran Benita ran...@gmail.com wrote:
  On Mon, Apr 02, 2012 at 12:04:25PM +0100, Daniel Stone wrote:
  Right, so allow it to call through arbitrary function pointers? I was
  considering doing that, but wasn't particularly feeling like dealing
  with the intracacies of varargs again that day.
 
  Varags aren't so bad. I had some fun abusing them here:
  https://github.com/bluetech/libxkbcommon/blob/tests2/test/keyseq.c
  That said, you can look at the libabc example code, if you think that's
  a better approach.

 Yeah, the tests look really good and we should definitely be doing
 that, I'm going to merge in a really minimal dataset too so we're not
 relying on an installed dataset for all our tests.  At that point we
 can go all-out and throw in a lot more tests for esoteric stuff like
 locking modifiers.

 I don't know if I'll have too much time to poke at the log stuff
 anytime soon, but it definitely sounds good.

  I'd like to be able to support full dumps (e.g. generated from xkbcomp
  -xkb :0 foo.txt) being loaded in to xkbcommon without triggering
  parsing errors because it doesn't have natural support for floats.
  That was the best way I found to do that; is there something I'm
  missing?
 
  Hmm, if I get it right, floats etc, can only appear inside xkb_geometry
  sections (which we treat as files). So the scanner should be able to lex
  them, but the parser can just skip the section and not have to know
  anything inside it. I'm not sure yacc does that off hand, I'll try it.
  Of course, it may be worth keeping for completeness or whatever.

 Hmm.  If it works then it'd definitely be a net win. :)

 Of course I didn't take a compiler class yet and so I hadn't realized
 yacc does bottom-up parsing, making this impossible... (at least in a
 straightforward way)

  Another question than :) We currently support three types of aggregate
  files, which are xkb_keymap, xkb_layout and xkb_semantics. The keymap
  can include all components (i.e. keycodes, symbols...), and the other
  two only one or two (mandatory / optional - see XKBcommonint.h
  #defines). Looking in /usr/share/X11/xkb, the layout type is completely
  unused, and there are a couple semantics files (which seem unused). So,
  is it worth keeping those? I don't think they serve any useful purpose?
  (unless someone tries to load them, but I don't think anyone has them
  lying around).

 No, we can jettison the other two.  In theory we need them for
 compatibility, but in reality they don't exist and I don't care.

 I have done this now. I've kept backward compatibility by just treating
 them as xkb_keymap in the parser. See the branch below.

  And lastly (I promise :), I'm thinking about a situation where there are
  several users of the library (say xserver, wayland/weston, kmscon,
  toolkits) and they all load a keymap from an rmlvo. Currently it seems
  like the end user would have to configure her preferred rmlvo separately
  for each one, which can get annoying (already..). Since you mentioned
  loading files from ~/.xkb/, would it make sense to support some simple
  config file for that? That way if the end

Re: [PATCH synaptics 0/3] synaptics indentation

2012-05-09 Thread Chase Douglas 
On 05/08/2012 07:18 PM, Peter Hutterer wrote:
 
 This has always annoyed me anyway and now that we managed to get the server
 done we might as well do synaptics. Same indentation style.

It's all fine by me.

Reviewed-by: Chase Douglas chase.doug...@canonical.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH synaptics] Don't check for soft buttons if a button is already down

2012-05-09 Thread Chase Douglas 
On 05/08/2012 11:36 PM, Peter Hutterer wrote:
 Moving into a different soft button's area during drag-n-drop would trigger
 a click of that button.
 
 http://bugzilla.redhat.com/819348
 
 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
  src/synaptics.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/synaptics.c b/src/synaptics.c
 index 7881926..e47d8ff 100644
 --- a/src/synaptics.c
 +++ b/src/synaptics.c
 @@ -2539,7 +2539,7 @@ update_hw_button_state(const InputInfoPtr pInfo, struct 
 SynapticsHwState *hw,
  
  /* If this is a clickpad and the user clicks in a soft button area, press
   * the soft button instead. */
 -if (para-clickpad  hw-left  !hw-right  !hw-middle) {
 +if (para-clickpad  hw-left  !hw-right  !hw-middle  
 !old-left) {
  if (is_inside_rightbutton_area(para, hw-x, hw-y)) {
  hw-left = 0;
  hw-right = 1;

Won't this do something wrong (e.g. not switch from left to right button
for right button area) for all events after the initial press event?

-- Chase
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH synaptics 09/10] Move synaptics.h leftovers to synapticsstr.h, drop synaptics.h

2012-05-09 Thread Chase Douglas 
On 05/08/2012 10:34 PM, Peter Hutterer wrote:
 This leaves us with a duplicated define for the maxbuttons but I'll live
 with that for now.

include/synaptics.h isn't fully removed as I expected from the subject
of this patch. Did I misinterpret things, or is the patch wrong?

-- Chase
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH synaptics 00/10] Purging features

2012-05-09 Thread Chase Douglas 
On 05/08/2012 10:34 PM, Peter Hutterer wrote:
 
 Well, features is probably pushing the term. More like bugs in disguise
 since several of those haven't been tested for multiple releases. The driver
 has become mostly unmaintainable, so a few features are shown the door.
 I'm sure things like trackstick emulation mode will be thouroughly missed,
 but I've heard Linux is all about choice and I choose not to maintain this
 any longer.
 
 This patchset requires the indentation patches I posted earlier.
 More features may take the trip to the chopping block in the future, no
 guarantees for now.

I don't have the bandwidth to actually review the code changes. However,
I agree in principle with them all, except patch 9.

I have a feeling the biggest issue will be edge support. Before we had
clickpad support, people relied on it to be able to click and drag
beyond the edge of the touchpad. There may be people who are now used to
using it. Obviously we have a better way of doing things now, though.

Acked-by: Chase Douglas chase.doug...@canonical.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] dix: disable all devices before shutdown

2012-05-09 Thread Chase Douglas 
On 05/08/2012 04:26 PM, Peter Hutterer wrote:
 f3410b97cf9b48a47bee3d15d232f8a88e75f4ef introduced a regression on server
 shutdown. If any button or key was held on shutdown (ctrl, alt, backspace
 are usually still down) sending a raw event will segfault the server. The
 the root windows are set to NULL before calling CloseDownDevices().
 
 Avoid this by disabling all devices first when shutting down. Disabled
 devices won't send events anymore.
 
 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net

Looks good to me.

Reviewed-by: Chase Douglas chase.doug...@canonical.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PULL libxkbcommon] Some more fixes and minor enhancements

2012-05-09 Thread Daniel Stone 
Hi,

On 9 May 2012 16:13, Ran Benita ran...@gmail.com wrote:
 On Tue, May 08, 2012 at 05:35:23PM +0100, Daniel Stone wrote:
 Thanks a bunch for all your last changes too, I've merged everything
 except the DFLT_XKB_CONFIG_ROOT change and the Unicode tests.  Again
 for the Unicode tests I want to use UTF-8 rather than UCS-4 and will
 get to this really quite soon now I promise (finally have some time to
 poke back at xkbcommon).

 Yes, but I think having UCS-4 makes sense as well, by which I mean that
 are applications (mine..) which have good reasons to use it. Since the
 existing implemantations (the libX11 one and the Markus Kuhn one)
 convert to uint32_t anyway, why not expose it in addition to UTF-8? So
 when you implement it please have a UCS-4 one :)

Ah, crap, I didn't realise people actually used that outside of
Windows.  Yeah, we can do both, I'll get to that RSN (after I've
finished up some Wayland core stuff), and merge Kristian's keysym
stuff at the same time.

 autotools makes me sad sometimes.

 Didn't know that; good that you caught it.

While we're here, the -I$(top_builddir)/src/xkbcomp is needed as
parser.h is generated during the build; it's slipped out of your
patches a couple of times and I've had to re-add it.  No biggie, but
just so you know.

 Yeah, I think we should have a global file and a per-user override
 too.  I'd like to see the following be possible:
     * xkbrc (or something): set the default names, which would allow
 us to pass NULL to the compilation functions and get the default
     * rules.local: amend the rules file
     * keymap.local: amend the compiled keymap

 This way hopefully no-one even remembers xmodmap exists.

 This sound good. I might try it some day.

 Finally, I had some time today to finish some stuff I started to remove
 more global state. It wasn't very fun but I managed to move
 xkb_intern_atom and friends into the context. I've now also put the
 patch mentioned above, and as always tried to sneak in a stylistic
 change :) It's based on your recent master:
        g...@github.com:bluetech/libxkbcommon.git contextualize
        https://github.com/bluetech/libxkbcommon/tree/contextualize
 Have a look when you've got time.

Cool! Yeah, I like it and have merged it.  Hilariously, at almost the
exact point in time (this morning, while I was on the train with no
internet access) you were changing context to ctx, I was changing xkb
(for xkb_keymaps) everywhere to keymap.  So I've merged this now but
there were a pretty staggering amount of conflicts.  Still, I now have
everything on your contextualize branch.

I think the only API issue I have now is renaming groups to layouts.
There's still a few bits internally but hopefully we should be good to
go pretty soon.

Since our trees seem to have mostly settled down by now, any
objections to me running uncrustify after I merge the keysym -
Unicode stuff?

Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PULL libxkbcommon] Some more fixes and minor enhancements

2012-05-09 Thread Ran Benita 
On Wed, May 09, 2012 at 06:20:35PM +0100, Daniel Stone wrote:
 On 9 May 2012 16:13, Ran Benita ran...@gmail.com wrote:
  On Tue, May 08, 2012 at 05:35:23PM +0100, Daniel Stone wrote:
  Thanks a bunch for all your last changes too, I've merged everything
  except the DFLT_XKB_CONFIG_ROOT change and the Unicode tests.  Again
  for the Unicode tests I want to use UTF-8 rather than UCS-4 and will
  get to this really quite soon now I promise (finally have some time to
  poke back at xkbcommon).
 
  Yes, but I think having UCS-4 makes sense as well, by which I mean that
  are applications (mine..) which have good reasons to use it. Since the
  existing implemantations (the libX11 one and the Markus Kuhn one)
  convert to uint32_t anyway, why not expose it in addition to UTF-8? So
  when you implement it please have a UCS-4 one :)
 
 Ah, crap, I didn't realise people actually used that outside of
 Windows.  Yeah, we can do both, I'll get to that RSN (after I've
 finished up some Wayland core stuff), and merge Kristian's keysym
 stuff at the same time.

Windows uses UTF-16, which is indeed crap. One-to-one mapping between
the encoding and the codepoint is nice sometimes (and it's what wchar_t
uses, outside of Windows at least).

  autotools makes me sad sometimes.
 
  Didn't know that; good that you caught it.
 
 While we're here, the -I$(top_builddir)/src/xkbcomp is needed as
 parser.h is generated during the build; it's slipped out of your
 patches a couple of times and I've had to re-add it.  No biggie, but
 just so you know.

Yes, I didn't notice you reverted it the first time, although I was sure I
had changed it :) Anyway thanks for teaching me something (I usually just
rely on make distcheck working).

  Yeah, I think we should have a global file and a per-user override
  too.  I'd like to see the following be possible:
      * xkbrc (or something): set the default names, which would allow
  us to pass NULL to the compilation functions and get the default
      * rules.local: amend the rules file
      * keymap.local: amend the compiled keymap
 
  This way hopefully no-one even remembers xmodmap exists.
 
  This sound good. I might try it some day.
 
  Finally, I had some time today to finish some stuff I started to remove
  more global state. It wasn't very fun but I managed to move
  xkb_intern_atom and friends into the context. I've now also put the
  patch mentioned above, and as always tried to sneak in a stylistic
  change :) It's based on your recent master:
         g...@github.com:bluetech/libxkbcommon.git contextualize
         https://github.com/bluetech/libxkbcommon/tree/contextualize
  Have a look when you've got time.
 
 Cool! Yeah, I like it and have merged it.  Hilariously, at almost the
 exact point in time (this morning, while I was on the train with no
 internet access) you were changing context to ctx, I was changing xkb
 (for xkb_keymaps) everywhere to keymap.  So I've merged this now but
 there were a pretty staggering amount of conflicts.  Still, I now have
 everything on your contextualize branch.
 
 I think the only API issue I have now is renaming groups to layouts.
 There's still a few bits internally but hopefully we should be good to
 go pretty soon.
 
 Since our trees seem to have mostly settled down by now, any
 objections to me running uncrustify after I merge the keysym -
 Unicode stuff?

Absolutely no objections. It might even make the code in rules.c
readable :)

Thanks for merging and handling the conflicts!
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] dix: disable all devices before shutdown

2012-05-09 Thread Julien Cristau 
On Wed, May  9, 2012 at 09:26:00 +1000, Peter Hutterer wrote:

 f3410b97cf9b48a47bee3d15d232f8a88e75f4ef introduced a regression on server
 shutdown. If any button or key was held on shutdown (ctrl, alt, backspace
 are usually still down) sending a raw event will segfault the server. The
 the root windows are set to NULL before calling CloseDownDevices().
 
 Avoid this by disabling all devices first when shutting down. Disabled
 devices won't send events anymore.
 
 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
  dix/devices.c   |   15 +++
  dix/main.c  |4 
  include/input.h |2 +-
  3 files changed, 20 insertions(+), 1 deletion(-)
 
One of the people who reported the corresponding debian bug says this
fixes the crash, but he gets [dix] cannot disable device, still paired.
This is a bug. twice on shutdown now.  Not sure if this is expected?

Cheers,
Julien


signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] dix: disable all devices before shutdown

2012-05-09 Thread Peter Hutterer 
On Wed, May 09, 2012 at 09:31:23PM +0200, Julien Cristau wrote:
 On Wed, May  9, 2012 at 09:26:00 +1000, Peter Hutterer wrote:
 
  f3410b97cf9b48a47bee3d15d232f8a88e75f4ef introduced a regression on server
  shutdown. If any button or key was held on shutdown (ctrl, alt, backspace
  are usually still down) sending a raw event will segfault the server. The
  the root windows are set to NULL before calling CloseDownDevices().
  
  Avoid this by disabling all devices first when shutting down. Disabled
  devices won't send events anymore.
  
  Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
  ---
   dix/devices.c   |   15 +++
   dix/main.c  |4 
   include/input.h |2 +-
   3 files changed, 20 insertions(+), 1 deletion(-)
  
 One of the people who reported the corresponding debian bug says this
 fixes the crash, but he gets [dix] cannot disable device, still paired.
 This is a bug. twice on shutdown now.  Not sure if this is expected?

I'll have a look, didn't see that message yesterday but I know where it
comes from.

Cheers,
  Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH synaptics 09/10] Move synaptics.h leftovers to synapticsstr.h, drop synaptics.h

2012-05-09 Thread Peter Hutterer 
On Wed, May 09, 2012 at 09:34:20AM -0700, Chase Douglas wrote:
 On 05/08/2012 10:34 PM, Peter Hutterer wrote:
  This leaves us with a duplicated define for the maxbuttons but I'll live
  with that for now.
 
 include/synaptics.h isn't fully removed as I expected from the subject
 of this patch. Did I misinterpret things, or is the patch wrong?

no, you're right, a rebase gone wrong. I squashed the git rm into this
patch now.

Cheers,
  Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH synaptics 00/10] Purging features

2012-05-09 Thread Peter Hutterer 
On Wed, May 09, 2012 at 09:37:02AM -0700, Chase Douglas wrote:
 On 05/08/2012 10:34 PM, Peter Hutterer wrote:
  
  Well, features is probably pushing the term. More like bugs in disguise
  since several of those haven't been tested for multiple releases. The driver
  has become mostly unmaintainable, so a few features are shown the door.
  I'm sure things like trackstick emulation mode will be thouroughly missed,
  but I've heard Linux is all about choice and I choose not to maintain this
  any longer.
  
  This patchset requires the indentation patches I posted earlier.
  More features may take the trip to the chopping block in the future, no
  guarantees for now.
 
 I don't have the bandwidth to actually review the code changes. However,
 I agree in principle with them all, except patch 9.
 
 I have a feeling the biggest issue will be edge support. Before we had
 clickpad support, people relied on it to be able to click and drag
 beyond the edge of the touchpad. There may be people who are now used to
 using it. Obviously we have a better way of doing things now, though.

the thing with the edge support is that I found it incredibly hard to
trigger and very unreliable. So I'd wager it wasn't used that commonly,
unless my touchpad is really that different to everyone else's.

 Acked-by: Chase Douglas chase.doug...@canonical.com

thanks.

Cheers,
  Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH synaptics 09/10] Move synaptics.h leftovers to synapticsstr.h, drop synaptics.h

2012-05-09 Thread Chase Douglas 
On 05/09/2012 04:24 PM, Peter Hutterer wrote:
 On Wed, May 09, 2012 at 09:34:20AM -0700, Chase Douglas wrote:
 On 05/08/2012 10:34 PM, Peter Hutterer wrote:
 This leaves us with a duplicated define for the maxbuttons but I'll live
 with that for now.

 include/synaptics.h isn't fully removed as I expected from the subject
 of this patch. Did I misinterpret things, or is the patch wrong?
 
 no, you're right, a rebase gone wrong. I squashed the git rm into this
 patch now.

Ok, with that change:

Acked-by: Chase Douglas chase.doug...@canonical.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH v2] Don't check for soft buttons if a button is already down

2012-05-09 Thread Peter Hutterer 
Moving into a different soft button's area during drag-n-drop would trigger
a click of that button.

We only have the current button state and we mess with it, so the conditions
for a possible clickpad soft-button event are:
- hw-left is down now
- none of left|right|middle were down before. since we change hw-left to
  hw-right/left we need to check all three

If hw-left is down but one of the other buttons was already down, copy that
button state and continue.

http://bugzilla.redhat.com/819348

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Changes to v1:
- check for all three buttons since we may have changed the hw-state for the
  right/middle button
- if left is down and was already down, copy the previous hardware state to
  maintain the right button state

 src/synaptics.c |   25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/src/synaptics.c b/src/synaptics.c
index 4f2bf78..6b95850 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -2538,14 +2538,23 @@ update_hw_button_state(const InputInfoPtr pInfo, struct 
SynapticsHwState *hw,
 
 /* If this is a clickpad and the user clicks in a soft button area, press
  * the soft button instead. */
-if (para-clickpad  hw-left  !hw-right  !hw-middle) {
-if (is_inside_rightbutton_area(para, hw-x, hw-y)) {
-hw-left = 0;
-hw-right = 1;
-}
-else if (is_inside_middlebutton_area(para, hw-x, hw-y)) {
-hw-left = 0;
-hw-middle = 1;
+if (para-clickpad) {
+/* hw-left is down, but no other buttons were already down */
+if (!old-left  !old-right  !old-middle 
+hw-left  !hw-right  !hw-middle) {
+if (is_inside_rightbutton_area(para, hw-x, hw-y)) {
+hw-left = 0;
+hw-right = 1;
+}
+else if (is_inside_middlebutton_area(para, hw-x, hw-y)) {
+hw-left = 0;
+hw-middle = 1;
+}
+}
+else if (hw-left) {
+hw-left = old-left;
+hw-right = old-right;
+hw-middle = old-middle;
 }
 }
 
-- 
1.7.10.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] xfree86: use udev to provide device enumeration for kms devices (v2)

2012-05-09 Thread Peter Hutterer 
On Wed, May 09, 2012 at 12:10:11PM +0100, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 On Linux in order for future hotplug work, we are required to interface
 to udev to detect device creation/removal. In order to try and get
 some earlier testing on this, this patch adds the ability to use
 udev for device enumeration on Linux.
 
 At startup the list of drm/kms devices is probed and this info is
 used to load drivers.
 
 A new driver probing method is introduced that passes the udev
 device info to the driver for probing.
 
 The probing integrates with the pci probing code and will fallback
 to the pci probe and old school probe functions in turn.
 
 The flags parameter to the probe function will be used later
 to provide hotplug and gpu screen flags for the driver to behave
 in a different way.
 
 This patch changes the driver ABI, all drivers should at least
 be set with a NULL udev probe function after this commit.
 
 v2: rename to platform bus, now with 100% less udev specific,
 
 this version passes config_odev_attribs around which are an array
 of id/string pairs, then the udev code can attach the set of attribs
 it understands, the OS specific code can attach its attrib, and then
 the core/drivers can lookup the required attribs.
 
 also add MATCH_PCI_DEVICES macro.
 
 This version is mainly to address concerns raised by ajax.
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  config/config-backends.h |1 +
  config/config.c  |8 +
  config/udev.c|   49 +
  configure.ac |   20 ++-
  hw/xfree86/common/Makefile.am|8 +-
  hw/xfree86/common/xf86.h |5 +
  hw/xfree86/common/xf86Bus.c  |   25 ++-
  hw/xfree86/common/xf86Bus.h  |1 +
  hw/xfree86/common/xf86fbBus.c|4 +
  hw/xfree86/common/xf86pciBus.c   |   17 ++-
  hw/xfree86/common/xf86pciBus.h   |5 +
  hw/xfree86/common/xf86platformBus.c  |  264 
 ++
  hw/xfree86/common/xf86platformBus.h  |   52 +
  hw/xfree86/common/xf86str.h  |   15 ++
  hw/xfree86/os-support/linux/Makefile.am  |2 +-
  hw/xfree86/os-support/linux/lnx_platform.c   |   87 +
  hw/xfree86/os-support/shared/platform_noop.c |   17 ++
  hw/xfree86/os-support/xf86_OSproc.h  |6 +
  include/dix-config.h.in  |3 +
  include/hotplug.h|   16 ++
  include/xorg-config.h.in |3 +
  include/xorg-server.h.in |3 +
  22 files changed, 599 insertions(+), 12 deletions(-)
  create mode 100644 hw/xfree86/common/xf86platformBus.c
  create mode 100644 hw/xfree86/common/xf86platformBus.h
  create mode 100644 hw/xfree86/os-support/linux/lnx_platform.c
  create mode 100644 hw/xfree86/os-support/shared/platform_noop.c
 
 diff --git a/config/config-backends.h b/config/config-backends.h
 index 62abc0a..6423701 100644
 --- a/config/config-backends.h
 +++ b/config/config-backends.h
 @@ -36,6 +36,7 @@ BOOL device_is_duplicate(const char *config_info);
  int config_udev_pre_init(void);
  int config_udev_init(void);
  void config_udev_fini(void);
 +void config_udev_odev_probe(config_odev_probe_proc_ptr probe_callback);
  #else
  
  #ifdef CONFIG_NEED_DBUS
 diff --git a/config/config.c b/config/config.c
 index 24e7ba7..07e920e 100644
 --- a/config/config.c
 +++ b/config/config.c
 @@ -85,6 +85,14 @@ config_fini(void)
  #endif
  }
  
 +void
 +config_odev_probe(config_odev_probe_proc_ptr probe_callback)
 +{
 +#if defined(CONFIG_UDEV_KMS)
 +config_udev_odev_probe(probe_callback);
 +#endif
 +}
 +
  static void
  remove_device(const char *backend, DeviceIntPtr dev)
  {
 diff --git a/config/udev.c b/config/udev.c
 index 1995184..a2d5aad 100644
 --- a/config/udev.c
 +++ b/config/udev.c
 @@ -366,3 +366,52 @@ config_udev_fini(void)
  udev_monitor = NULL;
  udev_unref(udev);
  }
 +
 +#ifdef CONFIG_UDEV_KMS
 +void
 +config_udev_odev_probe(config_odev_probe_proc_ptr probe_callback)
 +{
 +struct udev *udev;
 +struct udev_enumerate *enumerate;
 +struct udev_list_entry *devices, *device;
 +struct config_odev_attribute attribs[3];



 +
 +udev = udev_monitor_get_udev(udev_monitor);
 +enumerate = udev_enumerate_new(udev);
 +if (!enumerate)
 +return;
 +
 +udev_enumerate_add_match_subsystem(enumerate, drm);
 +udev_enumerate_add_match_sysname(enumerate, card[0-9]*);
 +udev_enumerate_scan_devices(enumerate);
 +devices = udev_enumerate_get_list_entry(enumerate);
 +udev_list_entry_foreach(device, devices) {
 +const char *syspath = udev_list_entry_get_name(device);
 +struct udev_device *udev_device = udev_device_new_from_syspath(udev, 
 syspath);
 +const char *path = udev_device_get_devnode(udev_device);
 +

[PULL] logging cleanups

2012-05-09 Thread Peter Hutterer 
The following changes since commit 97041364a6acb2b66b5cfd06757c90a006ad50e9:

  Merge remote-tracking branch 'whot/for-keith' (2012-05-02 20:47:25 -0700)

are available in the git repository at:


  git://people.freedesktop.org/~whot/xserver for-keith

for you to fetch changes up to c91d00e0f330b9de604068e1bfcb0a307096434f:

  os/log: refactor logging (2012-05-03 14:59:23 +1000)


Daniel Kurtz (4):
  os/log: trivial cleanups
  os/xprintf: add Xvscnprintf and Xscnprintf
  os/log: only write timestamp if a message is actually written to logfile
  os/log: refactor logging

 include/Xprintf.h |   12 ++
 os/log.c  |  105 +
 os/xprintf.c  |   44 ++
 3 files changed, 106 insertions(+), 55 deletions(-)


pgpizxvRY2Jsx.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH synaptics 06/10] Drop circular pad support

2012-05-09 Thread Eric Anholt 
On Wed,  9 May 2012 15:34:34 +1000, Peter Hutterer peter.hutte...@who-t.net 
wrote:
 Do such devices still exist?

Yeah, I use a 6 year old one as my i915 test system.  But then, it
doesn't have any particular synaptics configuration done to it, so I
guess the driver never knew it.  Nor do I understand what downside I
experienced from not having it set up.


pgpkJvf6RawdG.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH synaptics 06/10] Drop circular pad support

2012-05-09 Thread Peter Hutterer 
On Wed, May 09, 2012 at 08:27:29PM -0700, Eric Anholt wrote:
 On Wed,  9 May 2012 15:34:34 +1000, Peter Hutterer peter.hutte...@who-t.net 
 wrote:
  Do such devices still exist?
 
 Yeah, I use a 6 year old one as my i915 test system.  But then, it
 doesn't have any particular synaptics configuration done to it, so I
 guess the driver never knew it.  Nor do I understand what downside I
 experienced from not having it set up.

Instead of being a rectangle, the edge is the ellipse enclosed by the
Left/Right/Top/BottomEdge parameters.

pretty much sums it up, that's all it did.

Cheers,
  Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 0/1] Fix RANDR’s gamma_to_ramp()

2012-05-09 Thread Keith Packard 
On Tue, 08 May 2012 18:21:36 -0400, James Cloos cl...@jhcloos.com wrote:

 James Cloos (1):
   Fix RANDR’s gamma_to_ramp().

   e501c34..afc153a  master - master

-- 
keith.pack...@intel.com


pgp2erbL1DwpC.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PULL] logging cleanups

2012-05-09 Thread Keith Packard 
On Thu, 10 May 2012 12:51:15 +1000, Peter Hutterer peter.hutte...@who-t.net 
wrote:

 Daniel Kurtz (4):
   os/log: trivial cleanups
   os/xprintf: add Xvscnprintf and Xscnprintf
   os/log: only write timestamp if a message is actually written to logfile
   os/log: refactor logging

Merged
   afc153a..3a94b33  master - master

-- 
keith.pack...@intel.com


pgpiCrsLieHLG.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] include: add BUG_RETURN_* macros

2012-05-09 Thread Peter Hutterer 
Helper functions to avoid things like

if (foo) {
BUG_WARN(foo);
return 1;
}

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
 include/misc.h |9 +
 1 file changed, 9 insertions(+)

diff --git a/include/misc.h b/include/misc.h
index 41c1333..a57efa0 100644
--- a/include/misc.h
+++ b/include/misc.h
@@ -380,5 +380,14 @@ extern _X_EXPORT unsigned long serverGeneration;
   __BUG_WARN_MSG(cond, 1, __VA_ARGS__)
 
 #define BUG_WARN(cond)  __BUG_WARN_MSG(cond, 0, NULL)
+#define BUG_RETURN(cond) \
+do { __BUG_WARN_MSG(cond, 0, NULL); return; } while(0)
+#define BUG_RETURN_MSG(cond, ...) \
+do { __BUG_WARN_MSG(cond, 1, __VA_ARGS__); return; } while(0)
 
+#define BUG_RETURN_VAL(cond, val) \
+do { __BUG_WARN_MSG(cond, 0, NULL); return (val); } while(0)
+
+#define BUG_RETURN_VAL_MSG(cond, val, ...) \
+do { __BUG_WARN_MSG(cond, 1, __VA_ARGS__); return (val); } while(0)
 #endif  /* MISC_H */
-- 
1.7.10.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: libX11: Changes to 'master'

2012-05-09 Thread Jeremy Huddleston 
This commit introduced a 'make check' failure due by duplicating existing 
entries:

make[2]: Entering directory 
`/home/jeremy/src/freedesktop/jhbuild/src/xorg/lib/libX11/nls'
Clash with existing sequence in en_US.UTF-8/Compose on line 5826: Multi_key 
equal slash
  line #5826: Multi_key equal slash : ≠   U2260   # 
= / NOT EQUAL TO
  line #4533: Multi_key equal slash   : ≠   U2260 # NOT EQUAL TO
Clash with existing sequence in en_US.UTF-8/Compose on line 5827: Multi_key 
slash equal
  line #5827: Multi_key slash equal : ≠   U2260   # 
/ = NOT EQUAL TO
  line #4532: Multi_key slash equal   : ≠   U2260 # NOT EQUAL TO
Clash with existing sequence in en_US.UTF-8/Compose on line 5828: Multi_key 
underscore equal
  line #5828: Multi_key underscore equal: ≡   U2261   # 
_ = IDENTICAL TO
  line #4474: Multi_key underscore equal  : ₌   U208C # SUBSCRIPT 
EQUALS SIGN
Clash with existing sequence in en_US.UTF-8/Compose on line 5844: Multi_key 
parenleft minus
  line #5844: Multi_key parenleft minus : ⊢   U22a2   # 
( - RIGHT TACK
  line #73: Multi_key parenleft minus : {   braceleft # LEFT CURLY 
BRACKET
Clash with existing sequence in en_US.UTF-8/Compose on line 5845: Multi_key 
minus parenleft
  line #5845: Multi_key minus parenleft : ⊢   U22a2   # 
- ( RIGHT TACK
  line #74: Multi_key minus parenleft : {   braceleft # LEFT CURLY 
BRACKET
Clash with existing sequence in en_US.UTF-8/Compose on line 5846: Multi_key 
parenright minus
  line #5846: Multi_key parenright minus: ⊣   U22a3   # 
) - LEFT TACK
  line #83: Multi_key parenright minus: }   braceright # RIGHT 
CURLY BRACKET
Clash with existing sequence in en_US.UTF-8/Compose on line 5847: Multi_key 
minus parenright
  line #5847: Multi_key minus parenright: ⊣   U22a3   # 
- ) LEFT TACK
  line #84: Multi_key minus parenright: }   braceright # RIGHT 
CURLY BRACKET

make[2]: *** [check-TESTS] Error 1
make[1]: *** [check-am] Error 2
make: *** [check-recursive] Error 1

Clash with existing sequence in en_US.UTF-8/Compose on line 5929: Multi_key 
apostrophe underscore
  line #5929: Multi_key apostrophe underscore   : ⍘   U2358   # 
' _ APL FUNCTIONAL SYMBOL QUOTE UNDERBAR
  line #2041: Multi_key apostrophe underscore e : ḗ   U1E17 # 
LATIN SMALL LETTER E WITH MACRON AND ACUTE
  line #2247: Multi_key apostrophe underscore O : Ṓ   U1E52 # 
LATIN CAPITAL LETTER O WITH MACRON AND ACUTE
  line #2029: Multi_key apostrophe underscore E : Ḗ   U1E16 # 
LATIN CAPITAL LETTER E WITH MACRON AND ACUTE
  line #2259: Multi_key apostrophe underscore o : ṓ   U1E53 # 
LATIN SMALL LETTER O WITH MACRON AND ACUTE
Clash with existing sequence in en_US.UTF-8/Compose on line 5961: Multi_key 
diaeresis asciitilde
  line #5961: Multi_key diaeresis asciitilde: ⍨   U2368   # 
¨ ~ APL FUNCTIONAL SYMBOL TILDE DIAERESIS
  line #4237: Multi_key diaeresis asciitilde  : ῁   U1FC1 # GREEK 
DIALYTIKA AND PERISPOMENI
Clash with existing sequence in en_US.UTF-8/Compose on line 5965: Multi_key 
comma minus
  line #5965: Multi_key comma minus : ⍪   U236a   # 
, - APL FUNCTIONAL SYMBOL COMMA BAR
  line #499: Multi_key comma minus: ¬   notsign # NOT SIGN
Clash with existing sequence in en_US.UTF-8/Compose on line 5966: Multi_key 
minus comma
  line #5966: Multi_key minus comma : ⍪   U236a   # 
- , APL FUNCTIONAL SYMBOL COMMA BAR
  line #500: Multi_key minus comma: ¬   notsign # NOT SIGN
Clash with existing sequence in en_US.UTF-8/Compose on line 5977: Multi_key 
underscore semicolon
  line #5977: Multi_key underscore semicolon: ⍮   U236e   # 
_ ; APL FUNCTIONAL SYMBOL SEMICOLON UNDERBAR
  line #1405: Multi_key underscore semicolon O  : Ǭ   U01EC # LATIN 
CAPITAL LETTER O WITH OGONEK AND MACRON
  line #1414: Multi_key underscore semicolon o  : ǭ   U01ED # LATIN 
SMALL LETTER O WITH OGONEK AND MACRON
FAIL: ./compose-check.pl

1 of 1 test failed
Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=xorg

make[2]: Leaving directory 
`/home/jeremy/src/freedesktop/jhbuild/src/xorg/lib/libX11/nls'
make[1]: Leaving directory 
`/home/jeremy/src/freedesktop/jhbuild/src/xorg/lib/libX11/nls'


On May 8, 2012, at 12:49 PM, James Cloos cl...@kemper.freedesktop.org wrote:

 nls/en_US.UTF-8/Compose.pre |  185 
 
 1 file changed, 185 insertions(+)
 
 New commits:
 commit e51e37c118ae6cb9ced8244ce1c410677e0279ce
 Author: Geoff Streeter ge...@dyalog.com
 Date:   Thu Mar 22 15:02:00 2012 +
 
Add APL support to compose
 
Signed-off-by: Geoff Streeter ge...@dyalog.com
Signed-off-by: James Cloos cl...@jhcloos.com

Re: [PATCH] include: add BUG_RETURN_* macros

2012-05-09 Thread Peter Hutterer 
On Thu, May 10, 2012 at 02:25:25PM +1000, Peter Hutterer wrote:
 Helper functions to avoid things like
 
 if (foo) {
 BUG_WARN(foo);
 return 1;
 }
 
urgh, nevermind about this patch, it's bogus.

Cheers,
  Peter

 ---
  include/misc.h |9 +
  1 file changed, 9 insertions(+)
 
 diff --git a/include/misc.h b/include/misc.h
 index 41c1333..a57efa0 100644
 --- a/include/misc.h
 +++ b/include/misc.h
 @@ -380,5 +380,14 @@ extern _X_EXPORT unsigned long serverGeneration;
__BUG_WARN_MSG(cond, 1, __VA_ARGS__)
  
  #define BUG_WARN(cond)  __BUG_WARN_MSG(cond, 0, NULL)
 +#define BUG_RETURN(cond) \
 +do { __BUG_WARN_MSG(cond, 0, NULL); return; } while(0)
 +#define BUG_RETURN_MSG(cond, ...) \
 +do { __BUG_WARN_MSG(cond, 1, __VA_ARGS__); return; } while(0)
  
 +#define BUG_RETURN_VAL(cond, val) \
 +do { __BUG_WARN_MSG(cond, 0, NULL); return (val); } while(0)
 +
 +#define BUG_RETURN_VAL_MSG(cond, val, ...) \
 +do { __BUG_WARN_MSG(cond, 1, __VA_ARGS__); return (val); } while(0)
  #endif  /* MISC_H */
 -- 
 1.7.10.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] include: add BUG_RETURN_* macros

2012-05-09 Thread Keith Packard 
On Thu, 10 May 2012 14:25:25 +1000, Peter Hutterer peter.hutte...@who-t.net 
wrote:

 +#define BUG_RETURN(cond) \
 +do { __BUG_WARN_MSG(cond, 0, NULL); return; } while(0)

I'm not a huge fan of macros hiding control flow...

-- 
keith.pack...@intel.com


pgpKUGgs25PmH.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] include: add BUG_RETURN_* macros

2012-05-09 Thread Peter Hutterer 
On Wed, May 09, 2012 at 10:05:51PM -0700, Keith Packard wrote:
 On Thu, 10 May 2012 14:25:25 +1000, Peter Hutterer peter.hutte...@who-t.net 
 wrote:
 
  +#define BUG_RETURN(cond) \
  +do { __BUG_WARN_MSG(cond, 0, NULL); return; } while(0)
 
 I'm not a huge fan of macros hiding control flow...
 
these are bug macros. their only point is to scream BUG! into the log for
things that really shouldn't have happened.
right now we have a few of these:

BUG_WARN(foo);
if (foo)
return FALSE;

so we check the condition twice. That now becomes
BUG_RETURN_VAL(foo, FALSE)
which is less clutter, but fulfills the same purpose.

Cheers,
  Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: xserver: Branch 'server-1.12-branch' - 5 commits

2012-05-09 Thread Peter Hutterer 
On Wed, May 02, 2012 at 09:11:21PM -0700, Jeremy Huddleston wrote:
 commit 90299556db24543bb7365e8c2897deca3aa219e7
 Author: Peter Hutterer peter.hutte...@who-t.net
 Date:   Mon Apr 30 10:01:48 2012 +1000
 
 dix: when disabling a device, release all buttons and keys
 
 A suspend-induced device disable may happen before the device gets to see
 the button release event. On resume, the server's internal state still has
 some buttons pressed, causing inconsistent behaviour.
 
 Force the release and the matching events to be sent to the client.
 
 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 Reviewed-by: Chase Douglas chase.doug...@canonical.com
 (cherry picked from commit f3410b97cf9b48a47bee3d15d232f8a88e75f4ef)
 
 Conflicts:
 
   dix/devices.c
 
 diff --git a/dix/devices.c b/dix/devices.c
 index 0125504..d0e99bd 100644
 --- a/dix/devices.c
 +++ b/dix/devices.c
 @@ -432,6 +432,8 @@ DisableDevice(DeviceIntPtr dev, BOOL sendevent)
  if (*prev != dev)
  return FALSE;
  
 +ReleaseButtonsAndKeys(dev);
 +
  /* float attached devices */
  if (IsMaster(dev)) {
  for (other = inputInfo.devices; other; other = other-next) {


Jeremy, please revert this one on the 1.12 branch. It triggers a segfault on
server shutdown when a device posts raw events after the root windows are
forced to NULL.
https://lists.debian.org/debian-x/2012/05/msg00240.html

the fix for this is a bit of a rabbit-hole, too bit for 1.12 at this point.

Cheers,
  Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel