Re: [ANNOUNCE] Intel Releases IGD OpRegion Specification
Jesse Barnes wrote: The Intel Open Source Technology Center is pleased to announce the immediate availability of the ACPI Integrated Graphics Device OpRegion Specification[1] under the Creative Commons Attribution-No Derivative Works 3.0 United States License. This document is intended for use by graphics drivers developers and users to enable features such as ambient light sensor support and hotkey-driven display output switching. The IGD OpRegion interface is supported by video BIOS for all Intel® 965 Express Chipset family and newer chipsets. Initial support code is already available for the Linux kernel. The spec includes detailed descriptions of IGD OpRegion functions, APIs, and other interfaces to provide full software support. This release demonstrates Intel's continued commitment to supporting the free software community using the best practices of open source software development. [1] http://www.intellinuxgraphics.org/documentation.html Small question, intel recently released G45/G43 chipsets. The programming manual was released for G965/G35. Will there be updated manual for G45? Best regards, Maxim Levitsky ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] various xf86-input-synaptics cleanups
Following on from the recent removal of the repeater fifo from the synaptics
driver, these 3 patches clean up the code a bit:
01-synaptics-queryhardware-controlflow.diff simplifies the QueryHardware
function a bit.
02-synaptics-queryhardware-message.diff reintroduces a message that informs
the user that this driver cannot deal with the hardware for which it was
configured.
03-synaptics-remove-unused.diff removes an unused #define and some #includes
that were previously required for the fifo functionality.
Best Regards,
Magnus
Clean up control-flow
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/src/synaptics.c b/src/synaptics.c
index 148b3f6..8a6aeb7 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -2186,10 +2186,10 @@ QueryHardware(LocalDevicePtr local)
if (priv-proto_ops-QueryHardware(local, priv-synhw)) {
para-synhw = priv-synhw;
- return TRUE;
+} else {
+ priv-proto_ops-DeviceOffHook(local);
}
-priv-proto_ops-DeviceOffHook(local);
return TRUE;
}
Re-introduce message about unsupported touchpad that was dropped with the
repeater device removal.
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/src/synaptics.c b/src/synaptics.c
index 8a6aeb7..c1db1d2 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -2187,6 +2187,7 @@ QueryHardware(LocalDevicePtr local)
if (priv-proto_ops-QueryHardware(local, priv-synhw)) {
para-synhw = priv-synhw;
} else {
+ xf86Msg(X_PROBED, %s: no supported touchpad found\n, local-name);
priv-proto_ops-DeviceOffHook(local);
}
Remove unused defines and includes
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/src/synaptics.c b/src/synaptics.c
index c1db1d2..4b3a022 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -59,15 +59,10 @@
#endif
#include unistd.h
-#include sys/ioctl.h
#include misc.h
#include xf86.h
#include sys/shm.h
-#include sys/ipc.h
-#include sys/stat.h
-#include errno.h
#include math.h
-#include unistd.h
#include stdio.h
#include xf86_OSproc.h
#include xf86Xinput.h
@@ -92,7 +87,6 @@ typedef enum {
#define MAX(a, b) (((a)(b))?(a):(b))
#define MIN(a, b) (((a)(b))?(a):(b))
#define TIME_DIFF(a, b) ((int)((a)-(b)))
-#define SYSCALL(call) while (((call) == -1) (errno == EINTR))
#define SQR(x) ((x) * (x))
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/4] X event queue mutex
On Fri, 2008-10-03 at 05:57 +0300, Daniel Stone wrote: Except if the lock is held across the entire event processing, because we need to queue events from event processing. I guess that's what I meant with guaranteeing order. That makes it more important that the mutex cover precisely the values which will be modified in multiple threads, inserting events into the queue, and not pulling them out, which is done only in a single thread. Fine so far. But how do we touch structures which the IT uses before enqueuing from the main thread? E.g. with input properties, you're likely to modify IT-relevant data. I guess that's mostly a single write so visibility won't hurt much anyway, but there might be more complex ops. This should be considered a no-go or we need means to cope with it. A possiblity would be to lock the queue while processing prop handlers so the unlock guarantees visiblity, but this still doesn't provide a 100%-fix for data races. Opinions? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
Hi, On Tue, Sep 23, 2008 at 01:52:53PM +0930, Peter Hutterer wrote: driver kbd: hardcodes Ctrl + Alt + Backspace. (IMHO that's a bug anyway) driver evdev: the XKB map decides what happens. I don't know whether this is really related (I'm pretty sure I experienced that with kbd driver as well), but the fact that zap depends on xkb is actually quite problematic: When the xkb map is somehow borked, the server still starts, but it's not possible to zap (nor to switch console)... This gets really ugly when no other means to exit the server is available :-) -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xf86-video-nv-2.1.12 bug ?
Hi, I do need some help. I have an old nvidia card (GeForce2 MX/MX 400) and I have been using the nv_driver for quite some time on my GenToo system. After upgrading to xorg-server-1.5.0 (and 1.5.1 meanwhile) and x11-drivers/xf86-video-nv-2.1.12 I get short vertical black lines (of width 1 pixel) at the top and bottom of the window when moving a window quickly around. These lines vanish when the window is resized (just a bit) and reoccur when moving the window again. This is across several applications like jedit, nedit, opera, TclTk and xterm. Furthermore, when terminating X ( ctrlaltdel ) it doesn't shut down cleany, it doesn't accept any keys (like ctrlaltFx) anymore so than I have to reset the hardware to get out. These bugs have not been there with with previous versions of xorg-server and especially the xf86-video-nv driver. Since even the Nvidia legacy driver doesn't work with Xorg-server-1.5.x I'm in an unpleasant situation. from Xorg.0.log: (II) LoadModule: nv (II) Loading /usr/lib/xorg/modules/drivers//nv_drv.so (II) Module nv: vendor=X.Org Foundation compiled for 1.5.1, module version = 2.1.12 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 4.1 Are there any patches known? Many thanks for your help, Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-server-1.5.1 still sluggish
On Fri, Oct 3, 2008 at 4:30 PM, Markus Strobl [EMAIL PROTECTED] wrote: A few weeks ago there were some messages about 1.5.0 being sluggish (1-2 second pauses when switching tabs in firefox, delays in menus appearing etc). It looked like the cause was identified and tracked to a patch. I just tried 1.5.1 and the problem is still there so was just wondering what happened to the fix. Will it be part of 1.5.2 or should I file a bug report? Thanks, Markus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg If you're referring to the shm pixmap issue in combination with exa, then that made it in for 1.5.1. http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.5-branchid=ce6424853c2df2486ad99c0369974afc91a92993 Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-server-1.5.1 still sluggish
If you're referring to the shm pixmap issue in combination with exa, then that made it in for 1.5.1. http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.5-branchid=ce6424853c2df2486ad99c0369974afc91a92993 Maarten. Yep, that's the one. But the problem is still there. The pauses/freezes are so annoying I had to switch back to 1.4.2. Even just moving a window will freeze every second for a 1 second. Markus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Whence be libXevie tarball?
On Thu, Oct 2, 2008 at 12:19 PM, Julien Cristau [EMAIL PROTECTED] wrote: On Thu, Oct 2, 2008 at 11:41:34 -0500, Pat Kane wrote: Package evieproto was not found in the pkg-config search path. Perhaps you should add the directory containing `evieproto.pc' to the PKG_CONFIG_PATH environment variable No package 'evieproto' found The only reason I need it is to avoid that error message. Is there a way to tell X server not to need evieproto? evieproto != libXevie. The former is at http://xorg.freedesktop.org/archive/X11R7.4/src/proto/evieext-1.0.2.tar.bz2 Gak! Thanks, that fixed my build problem. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to implement alternate zap key idea
On Wed, 24 Sep 2008 09:22:47 +0100 David Gerard [EMAIL PROTECTED] wrote: 2008/9/23 Jaymz Julian [EMAIL PROTECTED]: FWIW, I tend to kill X not with ctrl-alt-bs but by going to a non-X console with ctrl-alt-F2 and sudo pkill Xorg. I suppose that's a bit Linux/FreeBSD-specific, of course. sshing in from another machine also works well. Don't forget to define an ACPI action, that does chvt 1 when you press Fn-F1 (or whatever) for the times, when xscreensaver's password window and qt-pinentry fight for the keyboard grab and the keyboard is stuck. Cheers, harry signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
On Fri, 3 Oct 2008 20:19:43 +0200 Harald Braumann [EMAIL PROTECTED] wrote: When zapping X is made impossible, users will find out about ctrl-prnt-b by accident. Sorry, I mean alt-prnt-b. signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-server-1.5.1 still sluggish
On Sat, Oct 4, 2008 at 2:12 AM, Markus Strobl [EMAIL PROTECTED] wrote: Maarten Maathuis wrote: On Fri, Oct 3, 2008 at 5:50 PM, Markus Strobl [EMAIL PROTECTED] wrote: If you're referring to the shm pixmap issue in combination with exa, then that made it in for 1.5.1. http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.5-branchid=ce6424853c2df2486ad99c0369974afc91a92993 Maarten. Yep, that's the one. But the problem is still there. The pauses/freezes are so annoying I had to switch back to 1.4.2. Even just moving a window will freeze every second for a 1 second. Markus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Is this just with firefox (or other mozilla apps)? Thunderbird is even worse. It took about 5 seconds to paint the reply window I'm typing this in, getting painted in section. Empty rectangle, then borders, then buttons, then text panes, etc. /Markus I meant, do non-mozilla applications also show this problem? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
