[PATCH] evdev: Add presure valuator (v2)
If it's available report pressure.
Signed-off-by: Matt Helsley
---
Changes:
Renamed pressure_valuator to has_pressure.
Nested some code blocks rather than having separate nearly
identical blocks.
Use xf86PostMotionEventP instead of the varargs wrapper.
NOTES:
I'm still working on generic valuator support.
Should apply with an offset of 16 if my "ABS_CNT" patch is
applied first.
src/evdev.c | 75
src/evdev.h |5 ++--
2 files changed, 63 insertions(+), 17 deletions(-)
Index: xf86-input-evdev/src/evdev.c
===
--- xf86-input-evdev.orig/src/evdev.c
+++ xf86-input-evdev/src/evdev.c
@@ -384,10 +384,14 @@ EvdevReadInput(InputInfoPtr pInfo)
break;
case ABS_Y:
pEvdev->abs_y = value;
abs = 1;
break;
+ case ABS_PRESSURE:
+ pEvdev->abs_p = value;
+ abs = 1;
+ break;
}
break;
case EV_KEY:
/* don't repeat mouse buttons */
@@ -475,30 +479,32 @@ EvdevReadInput(InputInfoPtr pInfo)
* pEvdev->digi here, lets us ignore that event. pEvdev is
* initialized to 1 so devices that doesn't use this scheme still
* just works.
*/
if (abs && pEvdev->tool) {
-int abs_x, abs_y;
-abs_x = (pEvdev->swap_axes) ? pEvdev->abs_y : pEvdev->abs_x;
-abs_y = (pEvdev->swap_axes) ? pEvdev->abs_x : pEvdev->abs_y;
+int v[3];
+v[0] = (pEvdev->swap_axes) ? pEvdev->abs_y : pEvdev->abs_x;
+v[1] = (pEvdev->swap_axes) ? pEvdev->abs_x : pEvdev->abs_y;
+v[2] = pEvdev->abs_p;
if (pEvdev->flags & EVDEV_CALIBRATED)
{
-abs_x = xf86ScaleAxis(abs_x,
+v[0] = xf86ScaleAxis(v[0],
pEvdev->max_x, pEvdev->min_x,
pEvdev->calibration.max_x, pEvdev->calibration.min_x);
-abs_y = xf86ScaleAxis(abs_y,
+v[1] = xf86ScaleAxis(v[1],
pEvdev->max_y, pEvdev->min_y,
pEvdev->calibration.max_y, pEvdev->calibration.min_y);
}
if (pEvdev->invert_x)
-abs_x = pEvdev->max_x - (abs_x - pEvdev->min_x);
+v[0] = pEvdev->max_x - (v[0] - pEvdev->min_x);
if (pEvdev->invert_y)
-abs_y = pEvdev->max_y - (abs_y - pEvdev->min_y);
+v[1] = pEvdev->max_y - (v[1] - pEvdev->min_y);
- xf86PostMotionEvent(pInfo->dev, TRUE, 0, 2, abs_x, abs_y);
+ xf86PostMotionEventP(pInfo->dev, TRUE, 0,
+2 + (pEvdev->has_pressure ? 1 : 0), v);
}
}
#define TestBit(bit, array) (array[(bit) / LONG_BITS]) & (1L << ((bit) %
LONG_BITS))
@@ -878,11 +884,12 @@ EvdevAddKeyClass(DeviceIntPtr device)
static int
EvdevAddAbsClass(DeviceIntPtr device)
{
InputInfoPtr pInfo;
EvdevPtr pEvdev;
-struct input_absinfo absinfo_x, absinfo_y;
+struct input_absinfo absinfo_x, absinfo_y, absinfo_p;
+int num_valuators = 2;
pInfo = device->public.devicePrivate;
pEvdev = pInfo->private;
if (ioctl(pInfo->fd,
@@ -900,11 +907,25 @@ EvdevAddAbsClass(DeviceIntPtr device)
pEvdev->min_x = absinfo_x.minimum;
pEvdev->max_x = absinfo_x.maximum;
pEvdev->min_y = absinfo_y.minimum;
pEvdev->max_y = absinfo_y.maximum;
-if (!InitValuatorClassDeviceStruct(device, 2,
+if (pEvdev->has_pressure &&
+ ioctl(pInfo->fd, EVIOCGABS(ABS_PRESSURE), &absinfo_p) < 0) {
+xf86Msg(X_ERROR, "ioctl EVIOCGABS ABS_PRESSURE failed: %s\n",
+ strerror(errno));
+ return !Success;
+}
+
+if (pEvdev->has_pressure) {
+ num_valuators++;
+ pEvdev->max_p = absinfo_p.maximum;
+ pEvdev->min_p = absinfo_p.minimum;
+}
+
+
+if (!InitValuatorClassDeviceStruct(device, num_valuators,
#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) < 3
GetMotionHistory,
#endif
GetMotionHistorySize(), Absolute))
return !Success;
@@ -916,10 +937,17 @@ EvdevAddAbsClass(DeviceIntPtr device)
/* Y valuator */
xf86InitValuatorAxisStruct(device, 1, pEvdev->min_y, pEvdev->max_y,
1, 0, 1);
xf86InitValuatorDefaults(device, 1);
+
+if (pEvdev->has_pressure) {
+ xf86InitValuatorAxisStruct(device, 2, pEvdev->min_p, pEvdev->max_p,
+ 1, 0, 1);
+ xf86InitValuatorDefaults(device, 2);
+}
+
xf86MotionHistoryAllocate(pInfo);
if (!InitPtrFeedbackClassDeviceStruct(device, EvdevPtrCtrlProc))
return !Success;
@@ -1365,11 +1393,11 @@ EvdevProbe(InputInfoPtr pInfo)
}
if (TestBit(ABS_X, abs_bitmask) && TestBit(ABS_Y, abs_bitmask)) {
[PATCH] evdev: Array sizes and iterations off by one
ABS_CNT (and friends) need to be used in some places instead of
ABS_MAX. Also "NBITS" seems misnamed -- it is really the number of
longs needed to hold the specified number of bits.
Signed-off-by: Matt Helsley
---
src/evdev.c | 24
src/evdev.h | 30 +++---
2 files changed, 35 insertions(+), 19 deletions(-)
Index: xf86-input-evdev/src/evdev.h
===
--- xf86-input-evdev.orig/src/evdev.h
+++ xf86-input-evdev/src/evdev.h
@@ -38,18 +38,34 @@
#ifdef XKB
#include
#endif
+#ifndef EV_CNT /* linux 2.4 kernels and earlier lack _CNT defines */
+#define EV_CNT (EV_MAX+1)
+#endif
+#ifndef KEY_CNT
+#define KEY_CNT (KEY_MAX+1)
+#endif
+#ifndef REL_CNT
+#define REL_CNT (REL_MAX+1)
+#endif
+#ifndef ABS_CNT
+#define ABS_CNT (ABS_MAX+1)
+#endif
+#ifndef LED_CNT
+#define LED_CNT (LED_MAX+1)
+#endif
+
#define EVDEV_MAXBUTTONS 32
#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 3
#define HAVE_PROPERTIES 1
#endif
#define LONG_BITS (sizeof(long) * 8)
-#define NBITS(x) (((x) + LONG_BITS - 1) / LONG_BITS)
+#define NLONGS(x) (((x) + LONG_BITS - 1) / LONG_BITS)
/* axis specific data for wheel emulation */
typedef struct {
int up_button;
int down_button;
@@ -118,16 +134,16 @@ typedef struct {
int reopen_left; /* number of attempts left to re-open the device */
OsTimerPtr reopen_timer;
/* Cached info from device. */
char name[1024];
-long bitmask[NBITS(EV_MAX)];
-long key_bitmask[NBITS(KEY_MAX)];
-long rel_bitmask[NBITS(REL_MAX)];
-long abs_bitmask[NBITS(ABS_MAX)];
-long led_bitmask[NBITS(LED_MAX)];
-struct input_absinfo absinfo[ABS_MAX];
+long bitmask[NLONGS(EV_MAX)];
+long key_bitmask[NLONGS(KEY_MAX)];
+long rel_bitmask[NLONGS(REL_MAX)];
+long abs_bitmask[NLONGS(ABS_MAX)];
+long led_bitmask[NLONGS(LED_MAX)];
+struct input_absinfo absinfo[ABS_CNT];
/* minor/major number */
dev_t min_maj;
} EvdevRec, *EvdevPtr;
Index: xf86-input-evdev/src/evdev.c
===
--- xf86-input-evdev.orig/src/evdev.c
+++ xf86-input-evdev/src/evdev.c
@@ -234,18 +234,18 @@ PostButtonClicks(InputInfoPtr pInfo, int
static void
PostKbdEvent(InputInfoPtr pInfo, struct input_event *ev, int value)
{
int code = ev->code + MIN_KEYCODE;
-static char warned[KEY_MAX];
+static char warned[KEY_CNT];
/* Filter all repeated events from device.
We'll do softrepeat in the server */
if (value == 2)
return;
-if (code > 255 && ev->code < KEY_MAX) {
+if (code > 255 && ev->code < KEY_CNT) {
if (!warned[ev->code])
xf86Msg(X_WARNING, "%s: unable to handle keycode %d\n",
pInfo->name, ev->code);
warned[ev->code] = 1;
}
@@ -1193,16 +1193,16 @@ EvdevCacheCompare(InputInfoPtr pInfo, BO
{
EvdevPtr pEvdev = pInfo->private;
int i;
char name[1024] = {0};
-long bitmask[NBITS(EV_MAX)] = {0};
-long key_bitmask[NBITS(KEY_MAX)] = {0};
-long rel_bitmask[NBITS(REL_MAX)] = {0};
-long abs_bitmask[NBITS(ABS_MAX)] = {0};
-long led_bitmask[NBITS(LED_MAX)] = {0};
-struct input_absinfo absinfo[ABS_MAX];
+long bitmask[NLONGS(EV_MAX)] = {0};
+long key_bitmask[NLONGS(KEY_MAX)] = {0};
+long rel_bitmask[NLONGS(REL_MAX)] = {0};
+long abs_bitmask[NLONGS(ABS_MAX)] = {0};
+long led_bitmask[NLONGS(LED_MAX)] = {0};
+struct input_absinfo absinfo[ABS_CNT];
if (ioctl(pInfo->fd,
EVIOCGNAME(sizeof(name) - 1), name) < 0) {
xf86Msg(X_ERROR, "ioctl EVIOCGNAME failed: %s\n", strerror(errno));
goto error;
@@ -1257,11 +1257,11 @@ EvdevCacheCompare(InputInfoPtr pInfo, BO
if (compare && memcmp(pEvdev->led_bitmask, led_bitmask,
sizeof(led_bitmask)))
goto error;
memset(absinfo, 0, sizeof(absinfo));
-for (i = 0; i < ABS_MAX; i++)
+for (i = 0; i < ABS_CNT; i++)
{
if (TestBit(i, abs_bitmask))
{
if (ioctl(pInfo->fd, EVIOCGABS(i), &absinfo[i]) < 0) {
xf86Msg(X_ERROR, "ioctl EVIOCGABS failed: %s\n",
strerror(errno));
@@ -1293,13 +1293,13 @@ error:
}
static int
EvdevProbe(InputInfoPtr pInfo)
{
-long key_bitmask[NBITS(KEY_MAX)] = {0};
-long rel_bitmask[NBITS(REL_MAX)] = {0};
-long abs_bitmask[NBITS(ABS_MAX)] = {0};
+long key_bitmask[NLONGS(KEY_MAX)] = {0};
+long rel_bitmask[NLONGS(REL_MAX)] = {0};
+long abs_bitmask[NLONGS(ABS_MAX)] = {0};
int i, has_axes, has_keys, num_buttons, has_scroll;
int kernel24 = 0;
EvdevPtr pEvdev = pInfo->private;
if (pEvdev->grabDevice && ioctl(pInfo->fd, EVIOCGRAB, (void *)1)) {
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] XFree86: fbdevhw: Add helper function to get fd
On Mon, 2009-01-05 at 11:38 +0200, Daniel Stone wrote:
> Most drivers need to do custom weird ioctls, so let them know what the
> fd is.
>
> Signed-off-by: Daniel Stone
> ---
> hw/xfree86/fbdevhw/fbdevhw.c |8
> hw/xfree86/fbdevhw/fbdevhw.h |2 ++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/hw/xfree86/fbdevhw/fbdevhw.c b/hw/xfree86/fbdevhw/fbdevhw.c
> index 5269277..495d88b 100644
> --- a/hw/xfree86/fbdevhw/fbdevhw.c
> +++ b/hw/xfree86/fbdevhw/fbdevhw.c
> @@ -152,6 +152,14 @@ fbdevHWFreeRec(ScrnInfoPtr pScrn)
> FBDEVHWPTRLVAL(pScrn) = NULL;
> }
>
> +int
> +fbdevHWGetFD(ScrnInfoPtr pScrn)
> +{
> +fbdevHWPtr fPtr = fbdevHWGetRec(pScrn);
fbdevHWGetRec returns a Bool, not a fbdevHWPtr.
Should this be 'fbdevHWPtr fPtr = FBDEVHWPTR(pScrn);' instead?
> +
> +return fPtr->fd;
> +}
> +
> /* */
> /* some helpers for printing debug informations */
>
> diff --git a/hw/xfree86/fbdevhw/fbdevhw.h b/hw/xfree86/fbdevhw/fbdevhw.h
> index 41c3e33..bc46b9c 100644
> --- a/hw/xfree86/fbdevhw/fbdevhw.h
> +++ b/hw/xfree86/fbdevhw/fbdevhw.h
> @@ -16,6 +16,8 @@
> extern _X_EXPORT Bool fbdevHWGetRec(ScrnInfoPtr pScrn);
> extern _X_EXPORT void fbdevHWFreeRec(ScrnInfoPtr pScrn);
>
> +extern _X_EXPORT int fbdevHWGetFD(ScrnInfoPtr pScrn);
> +
> extern _X_EXPORT Bool fbdevHWProbe(struct pci_device * pPci, char *device,
> char **namep);
> extern _X_EXPORT Bool fbdevHWInit(ScrnInfoPtr pScrn, struct pci_device *
> pPci, char *device);
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exclude programs from input device grabs
On Sat, Jan 10, 2009 at 05:23:24PM +, Patrick Sebastian Zimmermann wrote: > I searched around a bit and found that my WM (awesome) already grabs > the root window and still becomes unresponsive with a menu clicked or a > game running. Could it be that the necessary parts for this to work > (is that part of mpx?) are not in xserver 1.3? > If this is the case, then basicly everything I wanted to achieve has > already be done. once a grab has activated, only one client receives events. So if an app grabs the mouse, neither the WM nor anyone can actually receive events anymore. This is in fact one of the points of grabs. be careful about mixing terminology here, "grabbing a key" (which is what you wanted to do) generally means putting a passive grab on the keyboard for a specific key. You can have multiple of those, but while any grab is active, they cannot activate anymore. so I think what you want is a passive grab to activate while another grab is active and that simply isn't supported. Except for XEvIE, which I think routed all events unconditionally through the client. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Question about xkbd driver/x server interaction
On Sun, Jan 11, 2009 at 09:25:50AM +1300, Ian Welch wrote: > I'm very new to the internals of the X Server and its architecture and > have a newbie question. Am I right that the X Server creates a socket > connection to the keyboard via the xkbd driver and the X Server is > signalled when scan code data is available on the socket? yes, most drivers open an fd on the matching device file and put a SIGIO handler on the fd. The server then pulls the data off the fd during sigio handling, though the actual event processing (i.e. which client receives which event) is done in the main loop. one point to watch out is that linux systems tend to use the evdev driver for keyboards now, not kbd. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does X.org 7.4 work with Mesa 7.2?
Angel Tsankov wrote: > Jeremy Henty wrote: >> On Sat, Jan 10, 2009 at 05:53:56PM +0200, Angel Tsankov wrote: >>> (xdriinfo fails to configure saying that GL cannot be found)? >> >> I have found it necessary to run /sbin/ldconfig after installing >> Mesa, otherwise GL apps cannot find the GL shared libraries. Perhaps >> that is your problem? >> > It seems that X.org does not use the passed-in path (via -m to > build-from-tarballs.sh). ...to build Mesa. > This means that Mesa must be installed > prior to runnin build-from-tarballs.sh. However it depends on some of > the X.org packages. This does not lead to circular dependencies, but > it probably requires those packages to be built twice -- once to > satisfy Mesa's requirements and once more by build-from-tarballs.sh. Is > this really the case? > > I just modified build-from-tarballs.sh to build the dependencies, > stop so that I can install Mesa and then continue so that it builds > the rest of X.org. Now xdriinfo configures fine, but the even the > first compilation after that fails to find GL/glx.h which is in > /usr/local/include/glx.h (installed by xcb) and also in Mesa>/niclude/GL/glx/h (here was passed to > build-from-tarballs.sh via -m). I'm going to investigate this later > on. Hoever, any help in advance would be appreciated. > > --Angel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does X.org 7.4 work with Mesa 7.2?
Jeremy Henty wrote: > On Sat, Jan 10, 2009 at 05:53:56PM +0200, Angel Tsankov wrote: >> (xdriinfo fails to configure saying that GL cannot be found)? > > I have found it necessary to run /sbin/ldconfig after installing Mesa, > otherwise GL apps cannot find the GL shared libraries. Perhaps that > is your problem? > It seems that X.org does not use the passed-in path (via -m to build-from-tarballs.sh). This means that Mesa must be installed prior to runnin build-from-tarballs.sh. However it depends on some of the X.org packages. This does not lead to circular dependencies, but it probably requires those packages to be built twice -- once to satisfy Mesa's requirements and once more by build-from-tarballs.sh. Is this really the case? I just modified build-from-tarballs.sh to build the dependencies, stop so that I can install Mesa and then continue so that it builds the rest of X.org. Now xdriinfo configures fine, but the even the first compilation after that fails to find GL/glx.h which is in /usr/local/include/glx.h (installed by xcb) and also in /niclude/GL/glx/h (here was passed to build-from-tarballs.sh via -m). I'm going to investigate this later on. Hoever, any help in advance would be appreciated. --Angel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: (xkb) how to map a key to multiple characters?
To have a key ouput a string rather than a single character, you have to use XIM or something like that. We'll need to add keysyms for the CH digraph and C'H trigraph and appropriate mappings for them in the Compose tables. Please open a bug report at: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg requesting the keysyms and Compose mapping. Do you have a reference to an explanation of how casing works in Breton, with respect to these multi-character letters? Projects like Gnome use their own Compose tables; you'll also need to ask them to add a similar Compose mapping once we determine what it should be. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does X.org 7.4 work with Mesa 7.2?
On Sat, Jan 10, 2009 at 05:53:56PM +0200, Angel Tsankov wrote: > (xdriinfo fails to configure saying that GL cannot be found)? I have found it necessary to run /sbin/ldconfig after installing Mesa, otherwise GL apps cannot find the GL shared libraries. Perhaps that is your problem? Regards, Jeremy Henty ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver distribution missing sdksyms.sh
On Monday 05 January 2009 11:03:55 pm Paulo César Pereira de Andrade wrote: > vehemens wrote: > > subject says it all > > Thanks. I feel dumb for this one :-) Last time > I run make distcheck was like one month ago, when > I added > DISTCLEANFILES = doltcompile doltlibtool > to the toplevel Makefile.am I always build using tar balls, and I wait about a month before mentioning this type of problem :> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
(xkb) how to map a key to multiple characters?
Hi
I'm trying to create a new keyboard layout with xbd for X11 on
Linux for the C'HWERTY Breton keyboard.
This keyboard is a bit unusual because it has a C'H key and
pressing this key should result in 3 characters being emitted: C,
apostrophe and H. It also has a CH key which should result
in 2 characters being emitted: C and H.
You can see a photo of this keyboard with the "C'H" and "CH" there:
http://upload.wikimedia.org/wikipedia/commons/9/9e/Bretona-klavaro.jpg
Notice the C'H key for example near the top left, below the 1 and 2 keys.
C'H and CH are considered as single letters in Breton but Unicode has
no such code for the C'H trigraph or CH digraph (unlike IJ in Dutch
for example which is a single character in Unicode).
I'm new to creating keyboard layout with X. I'm mostly done.
I have created a file in /usr/share/X11/xkb/symbols/ (Ubuntu-8.10)
and associated associate keys to characters with a bunch of
lines like these
...snip...
key { [ u, U
] };
key { [ i, I
] };
key { [ o, O, oe,
OE ] };
key { [ p, P
] };
...snip...
It mostly works. However, there is one problem which I have not been
able to solve yet:
--> How to associate multiple characters to a key? (for the C'H and CH keys)
Hopefully that's possible. The keyboard works well on Windows, but
I'd like to add support and use it with Linux.
Thanks
--
Dominique
http://dominiko.livejournal.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: backlight problems on intel and new stuff
Nope, I use 2.6.28, and have thinkpad_acpi loaded. Vedran On Fri, Jan 9, 2009 at 4:46 PM, Sergio Monteiro Basto wrote: > On Fri, 2009-01-09 at 11:32 +0100, Vedran Rodic wrote: >> 2.3.2-2+lenny5 > ok have you have an empty /sys/class/backlight/ ? > > ll /sys/class/backlight/ > > thanks, > -- > Sérgio M. B. > -- Vedran Rodic Novalis d.o.o. Mobile phone: + 385 99 312 6138 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Question about xkbd driver/x server interaction
Hi, I'm very new to the internals of the X Server and its architecture and have a newbie question. Am I right that the X Server creates a socket connection to the keyboard via the xkbd driver and the X Server is signalled when scan code data is available on the socket? Thanks, Ian Welch -- Ian Welch, Victoria University of Wellington, New Zealand http://opusiti.wordpress.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Brainstorm] LinkKit for Xorg
Paulo � wrote: > R�mi Cardona wrote: >> Le 10/01/2009 03:10, Paulo C�sar Pereira de Andrade a �crit : >>> Xorg (and to some extent XFree86) loadable modules >>> aren't really of much use, as modules cannot be properly >>> unloaded, there is no dependency information; a module >>> doesn't list it's dependencies in any form, causing >>> frequently one to need to load a lot more code/data >>> then required. >> Hi Paulo, > >Hi R�mi, > >> Why not implement that instead? Sounds like reviving LinkKit will bring >> more cruft rather than clean up the current code... > >The amount of work for either should be similar, just that if > you have a "closed binary", it must have all symbols resolved. > The "cool" thing about loadable modules would be to be able to > switch/disable/enable input/video/etc modules on the fly, but this > is not a reality, and requires restarting the X Server anyway... > I know I might get dogpiled for this, but why does it necessarily have to require an X server restart? Right now, for example, VT switches seem pretty close to having an X server restart (at least for some parts of it). It certainly would be nice to be able to update drivers and other bits without having to restart X, in much the same way that it would be nice to be able to update the kernel without restarting it. Other benefits could include the ability to detach/reattach/move X servers like you can do with screen and twin. I am not signing myself up to do this ;) >> What's your ulterior motives with LinkKit anyway? Just curious :) > >None really, but maybe someone that worked on it is reading > the lists and could also comment, or maybe some vague memory > of transforming an "unusable" computer in one that could even > run emacs (I used to use emacs to edit sources, read email, > compile, debug, etc) :-) >I just cited it because it used the concept I was thinking about, > http://www.xfree.org/3.3.6/LinkKit1.html. > >> Cheers, >> >> R�mi > > Paulo > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-mouse 1.4.0
Beso wrote: > i was curious just about another thing: is or will ever be there a > project for an evdev port > on solaris and opensolaris? i think that evdev is one of that drivers > that worth porting if there is > the possibility. I don't know if our kernel guys will be doing that (it would have to be a reimplementation instead of a port of the kernel driver due to the license issues).When I discussed porting the xf86-input-evdev to work with the existing Solaris input interfaces, the people who know that driver suggested it probably wasn't a good idea, so I'll probably end up stealing code from the xf86-input-evdev module to add new Xi features like input properties to xf86-input-kbd and xf86-input-mouse at some point (though if someone else is interested enough to beat me to it, please go ahead! My to-do list is always far longer than I can ever get to.) -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Brainstorm] LinkKit for Xorg
Rémi Cardona wrote: > Le 10/01/2009 03:10, Paulo César Pereira de Andrade a écrit : >>Xorg (and to some extent XFree86) loadable modules >> aren't really of much use, as modules cannot be properly >> unloaded, there is no dependency information; a module >> doesn't list it's dependencies in any form, causing >> frequently one to need to load a lot more code/data >> then required. > > Hi Paulo, Hi Rémi, > Why not implement that instead? Sounds like reviving LinkKit will bring > more cruft rather than clean up the current code... The amount of work for either should be similar, just that if you have a "closed binary", it must have all symbols resolved. The "cool" thing about loadable modules would be to be able to switch/disable/enable input/video/etc modules on the fly, but this is not a reality, and requires restarting the X Server anyway... > What's your ulterior motives with LinkKit anyway? Just curious :) None really, but maybe someone that worked on it is reading the lists and could also comment, or maybe some vague memory of transforming an "unusable" computer in one that could even run emacs (I used to use emacs to edit sources, read email, compile, debug, etc) :-) I just cited it because it used the concept I was thinking about, http://www.xfree.org/3.3.6/LinkKit1.html. > Cheers, > > Rémi Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-mouse 1.4.0
2009/1/10 Alan Coopersmith : > Beso wrote: >> 2009/1/10 Alan Coopersmith : >>> Rémi Cardona wrote: Le 10/01/2009 05:45, Alan Coopersmith a écrit : > The big change in 1.4.0 is the move of the OS-specific mouse handling code > from the Xorg server to the mouse driver. This code was removed from the > Xorg server in the Xorg 1.6 development cycle, so users of non-evdev > systems > (i.e. non-Linux or pre-evdev Linux) will need this version of the mouse > driver > to run with Xorg 1.6. >> >>> It was moved to the module because the server never calls it >>> directly - only the mouse module does, and if you're using another driver, >>> like evdev or void, then the code is never called at all. >>> >> i'm confused: if the code is never called by the server or evdev >> what's the reason for >> evdev to need it to run with 1.6 as you've stated in the previous mail? > > Read it again - I wrote "users of *non*-evdev systems...will need this". > i.e. I need it for my Solaris packages, and the BSD folks will need it, > but common modern Linux distros could just delete the mouse module altogether > if they're ready to go evdev-only. (If you do ship the mouse module at all > with Xorg 1.6, you'll need this to avoid dlopen errors on the mouse module > of not being able to find the xf86OSMouseInit function that moved from the > server to the module.) > sorry to have bothered you... :-( it seems that for today i've had enough time in front of the monitor with oracle and i need a pause. i was curious just about another thing: is or will ever be there a project for an evdev port on solaris and opensolaris? i think that evdev is one of that drivers that worth porting if there is the possibility. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-mouse 1.4.0
Beso wrote: > 2009/1/10 Alan Coopersmith : >> Rémi Cardona wrote: >>> Le 10/01/2009 05:45, Alan Coopersmith a écrit : The big change in 1.4.0 is the move of the OS-specific mouse handling code from the Xorg server to the mouse driver. This code was removed from the Xorg server in the Xorg 1.6 development cycle, so users of non-evdev systems (i.e. non-Linux or pre-evdev Linux) will need this version of the mouse driver to run with Xorg 1.6. > >> It was moved to the module because the server never calls it >> directly - only the mouse module does, and if you're using another driver, >> like evdev or void, then the code is never called at all. >> > i'm confused: if the code is never called by the server or evdev > what's the reason for > evdev to need it to run with 1.6 as you've stated in the previous mail? Read it again - I wrote "users of *non*-evdev systems...will need this". i.e. I need it for my Solaris packages, and the BSD folks will need it, but common modern Linux distros could just delete the mouse module altogether if they're ready to go evdev-only. (If you do ship the mouse module at all with Xorg 1.6, you'll need this to avoid dlopen errors on the mouse module of not being able to find the xf86OSMouseInit function that moved from the server to the module.) -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-mouse 1.4.0
2009/1/10 Alan Coopersmith : > Rémi Cardona wrote: >> Le 10/01/2009 05:45, Alan Coopersmith a écrit : >>> The big change in 1.4.0 is the move of the OS-specific mouse handling code >>> from the Xorg server to the mouse driver. This code was removed from the >>> Xorg server in the Xorg 1.6 development cycle, so users of non-evdev systems >>> (i.e. non-Linux or pre-evdev Linux) will need this version of the mouse >>> driver >>> to run with Xorg 1.6. > It was moved to the module because the server never calls it > directly - only the mouse module does, and if you're using another driver, > like evdev or void, then the code is never called at all. > i'm confused: if the code is never called by the server or evdev what's the reason for evdev to need it to run with 1.6 as you've stated in the previous mail? -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exclude programs from input device grabs
I searched around a bit and found that my WM (awesome) already grabs the root window and still becomes unresponsive with a menu clicked or a game running. Could it be that the necessary parts for this to work (is that part of mpx?) are not in xserver 1.3? If this is the case, then basicly everything I wanted to achieve has already be done. Greetings, Patrick On Fri, 9 Jan 2009 10:08:09 +1000 Peter Hutterer wrote: > On Thu, Jan 08, 2009 at 10:48:48PM +, Patrick Sebastian > Zimmermann wrote: > > I want that a chosen application (in my case a hotkey daemon) > > receives all input device events even when they are grabbed by other > > applications. Even though I don't yet know the X internals, I guess > > this is not done by simply grabbing all input devices. This would > > allow any program to overhear passwords. > > This is the wrong way to do it though. XEvIE has it's purpose, but > this is not it. The correct solution to your problem is to simply > grab the keys on the root window. If the key is already grabbed, then > there's a change the desktop environment/WM already grabbed the key, > so you should either pick a different shortcut, or integrate into the > DE. > > On Thu, 08 Jan 2009 11:44:21 -0500 > > Thomas Jaeger wrote: > > > > > What is it exactly that you want to do? If you just want to be > > > notified of key presses, all you have to do is grab the key on all > > > the extended input devices. In xserver 1.6, if you also want > > > applications not to receive the events, you can change the core > > > pointer mapping. If I understood Peter correctly, come XI 2.0, > > > this won't be necessary anymore since grabs will temporarily > > > detach the slave device. > > > > > > Tom > > > > > > Patrick Sebastian Zimmermann wrote: > > > > I searched around a bit. > > > > Did I get it right, that mpx changed the entire input part of X > > > > and therefor XEvIE didn't work anymore and was removed. mpx > > > > does not provide anything like input redirection, so bringing > > > > back XEvIE based on the new input logic mpx brings would not > > > > result in implementing the same feature twice, right? > > > > If this is the case I will try to bring XEvIE back. > > sort-of, IIRC XEvIE was already quite broken before the mpx merge. > mpx just kicked it again to make sure it's dead. > > Cheers, > Peter > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-mouse 1.4.0
Rémi Cardona wrote:
> Le 10/01/2009 05:45, Alan Coopersmith a écrit :
>> The big change in 1.4.0 is the move of the OS-specific mouse handling code
>> from the Xorg server to the mouse driver. This code was removed from the
>> Xorg server in the Xorg 1.6 development cycle, so users of non-evdev systems
>> (i.e. non-Linux or pre-evdev Linux) will need this version of the mouse
>> driver
>> to run with Xorg 1.6.
>
> Hi Alan,
>
> Just wondering: can this version of xf86-input-mouse get along with Xorg
> 1.5 or will they both attempt to control the same OS-specific details?
It seemed to work fine with the 1.5.3 server I tested on - you'll just have
two copies of the ${OS}_mouse.c code present, one in the server, one in the
module. It was moved to the module because the server never calls it
directly - only the mouse module does, and if you're using another driver,
like evdev or void, then the code is never called at all.
--
-Alan Coopersmith- alan.coopersm...@sun.com
Sun Microsystems, Inc. - X Window System Engineering
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Proposed server-1.6 enterleave/focusinout patches
'Twas brillig, and Keith Packard at 09/01/09 19:48 did gyre and gimble: > I've pushed a proposed set of patches that merge in Peter's new > enterleave/focusinout stuff on the 1.6 branch. It's all on the > server-1.6-enterleave branch and I'd like comments on whether that code > looks right. Mostly what I did was eliminate all of the Device events by > #if 0'ing the code. I did that to reduce the size of the diffs against > the master versions of the files; otherwise there would be a large diff > and merging future fixes would be harder. I updated the mandriva cooker package to this branch and removed the old workaround patch we had for it. Seems to be working fine for me so far (the bug that I had before with firefox link hovers is certainly not rearing it's ugly head) but will report any abnormalities that other user may report to me. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Does X.org 7.4 work with Mesa 7.2?
I'm trying to build X.org 7.4 (from tarballs with build_from_tarballs.sh) with Mesa and I have the following questions: 1. May I use a version of Mesa later than the recommended, e.g.7.2? 2. Do I have to install Mesa prior to running build_from_tarballs.sh (xdriinfo fails to configure saying that GL cannot be found)? Regards, Angel Tsankov ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Add language about implicit flush and command completion
On Fri, 2009-01-09 at 18:32 -0800, Ian Romanick wrote: > Copied language from the glXSwapBuffers manual page about the implicit > glFlush and expected command completion. This just codifies what > people already expect from glXCopySubBufferMESA. The intention of > this command is to work like glXSwapBuffers but on a sub-rectangle of > the drawable. [...] > +glXCopySubBufferMESA performs an implicit glFlush before it > +returns. Subsequent OpenGL commands may be issued immediately > +after calling glXCopySubBufferMESA, but are not executed until the > +copy is completed. Note that the GLX spec is a little more complicated wrt this, it says: If dpy and draw are the display and drawable for the calling thread’s current context, glXSwapBuffers performs an implicit glFlush. (I think the Mesa glXSwapBuffers code doesn't currently conform to this but unconditionally performs the implicit glFlush) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Brainstorm] LinkKit for Xorg
Le 10/01/2009 03:10, Paulo César Pereira de Andrade a écrit : >Xorg (and to some extent XFree86) loadable modules > aren't really of much use, as modules cannot be properly > unloaded, there is no dependency information; a module > doesn't list it's dependencies in any form, causing > frequently one to need to load a lot more code/data > then required. Hi Paulo, Why not implement that instead? Sounds like reviving LinkKit will bring more cruft rather than clean up the current code... What's your ulterior motives with LinkKit anyway? Just curious :) Cheers, Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-mouse 1.4.0
Le 10/01/2009 05:45, Alan Coopersmith a écrit : > The big change in 1.4.0 is the move of the OS-specific mouse handling code > from the Xorg server to the mouse driver. This code was removed from the > Xorg server in the Xorg 1.6 development cycle, so users of non-evdev systems > (i.e. non-Linux or pre-evdev Linux) will need this version of the mouse driver > to run with Xorg 1.6. Hi Alan, Just wondering: can this version of xf86-input-mouse get along with Xorg 1.5 or will they both attempt to control the same OS-specific details? Thanks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] : quirk for AOpen MP45
Hi
I own an AOpen MP45 mini-pc which doesn't have an LVDS output although
xorg reports one.
Like for the other mini-pc, this patch solves the problem.
Thanks
Vincent
---
diff -Naubr xf86-video-intel-2.5.99.2/src/i830_quirks.c
xf86-video-intel-2.5.99.2.new/src/i830_quirks.c
--- xf86-video-intel-2.5.99.2/src/i830_quirks.c 2009-01-08
07:32:38.0 +0100
+++ xf86-video-intel-2.5.99.2.new/src/i830_quirks.c 2009-01-10
08:49:18.0 +0100
@@ -233,6 +233,7 @@
{ PCI_CHIP_I915_GM, 0xa0a0, SUBSYS_ANY, quirk_ignore_lvds },
{ PCI_CHIP_I945_GM, 0xa0a0, SUBSYS_ANY, quirk_ignore_lvds },
{ PCI_CHIP_I965_GM, 0xa0a0, SUBSYS_ANY, quirk_ignore_lvds },
+{ PCI_CHIP_GM45_GM, 0xa0a0, SUBSYS_ANY, quirk_ignore_lvds },
{ PCI_CHIP_I965_GM, 0x8086, 0x1999, quirk_ignore_lvds },
/* Apple Mac mini has no lvds, but macbook pro does */
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
