newest drivers lose X-video support?
Hello, I recently installed updated versions of xserver-xorg-video-intel (2.5.1-1ubuntu5), libdrm2 and libdrm-intel1 (2.4.1-0ubuntu7) in order to try to resolve a suspend-to-RAM bug. I installed files from this archive: https://edge.launchpad.net/~intel-gfx-testing/+archive The fix appears to have worked, but an apparent side-effect is that I have lost X-video support. xvinfo returns: $ xvinfo X-Video Extension version 2.2 screen #0 no adaptors present $ The XVideo extension is still being loaded: $ grep -i xvideo /var/log/Xorg.0.log (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation $ I'm pretty sure it used to work because mplayer, which ran fine before the upgrade, no longer functions with hardware acceleration; I have to fall back to unaccelerated video output. The chipset is a Mobile Intel GM45 [hardware is a Lenovo x200]. Any idea how I can resolve this problem? Thanks in advance, Brandon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fwd: wrong colors with Xv extension and image format id: 0x59565955 (UYVY) from an rgb mapping
On 01/23/2009 02:59 AM, Amos Tibaldi wrote:
#define GUID_UYVY_PLANAR 0x59565955
Just a sidenote: This is misleading, that format is packed and not planar.
void RGBToUV(unsigned short int r,
unsigned short int g,
unsigned short int b,
unsigned short int * u,
unsigned short int * v)
{
*u = -0.147 * r +
-0.289 * g +
0.436 * b; // min(abs(r * -1214 + g * -2384 + b * 3598 + 4096 + 1048576)
13, 240);
//(unsigned short int)(-0.147f*(float)r-0.289f*(float)g+0.436f*(float)b);
*v = 0.615 * r +
-0.515 * g +
-0.100 * b;
//min(abs(r * 3598 + g * -3013 + b * -585 + 4096 + 1048576) 13, 240);
//(unsigned short int)(0.615f*(float)r-0.515f*(float)g-0.100f*(float)b);
}
void RGBToY(unsigned short int r,
unsigned short int g,
unsigned short int b,
unsigned short int * y
)
{
*y = 0.299 * r +
0.587 * g +
0.114 * b; // min(abs(r * 2104 + g * 4130 + b * 802 + 4096 + 131072)
13, 235);
//(unsigned short int)(0.299f*(float)r+0.587f*(float)g+0.114f*(float)b);
}
The formulas that are in use are wrong. You need to scale and shift the
YUV values. The formulas that you commented out are correct and yield
the correct colors here (min(abs(...) 13, 235)). These formulas also
worked in my test:
*y = ( ( 66 * r + 129 * g + 25 * b + 128) 8) + 16;
*u = ( ( -38 * r - 74 * g + 112 * b + 128) 8) + 128;
*v = ( ( 112 * r - 94 * g - 18 * b + 128) 8) + 128;
See wikipedia or msdn:
http://msdn.microsoft.com/en-us/library/ms893078.aspx
http://en.wikipedia.org/wiki/YUV#Numerical_approximations
tom
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: restoring XvMC with DRI2 with xf86-video-intel-2.6.0
Antoine Martin wrote: There is a commit named: Disable XvMC on DRI2 for now [...] Are there any plans to re-enable it in 2.6.1? 2.6.1 is out already, so that won't be the case. Have a look at 10c63fad690c13458f0b32bced571f1403d74...@pdsmsx502.ccr.corp.intel.com, Gordon Jin stated: Right, this doesn't work so zhenyu disabled it in this release. I'm not sure when it can be worked out. Cheers, Johannes ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Xi: define a default range of axis labels.
Peter Hutterer wrote:
patches welcome :)
Here y'r. :)
From e25f0f7c38c9f5d5cfab4a20fe42ee5cbf38d012 Mon Sep 17 00:00:00 2001
From: Simon Thum simon.t...@gmx.de
Date: Fri, 23 Jan 2009 11:39:56 +0100
Subject: [PATCH] xinput: create well-known atoms on demand, rather than preinit
them
---
Xi/extinit.c|1 -
Xi/xiproperty.c | 32
Xi/xiproperty.h |2 --
3 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/Xi/extinit.c b/Xi/extinit.c
index 62ec958..a7a21ec 100644
--- a/Xi/extinit.c
+++ b/Xi/extinit.c
@@ -1143,7 +1143,6 @@ XInputExtensionInit(void)
IEventBase = extEntry-eventBase;
AllExtensionVersions[IReqCode - 128] = thisversion;
MakeDeviceTypeAtoms();
- XIInitKnownProperties();
RT_INPUTCLIENT = CreateNewResourceType((DeleteType) InputClientGone);
RegisterResourceName(RT_INPUTCLIENT, INPUTCLIENT);
FixExtensionEvents(extEntry);
diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index 53b2f6a..db32735 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -60,7 +60,7 @@ static struct dev_properties
static long XIPropHandlerID = 1;
/**
- * Return the type assigned to the specified atom or 0 if the atom isn't known
+ * Return the atom assigned to the specified string or 0 if the atom isn't
known
* to the DIX.
*/
Atom
@@ -69,8 +69,18 @@ XIGetKnownProperty(char *name)
int i;
for (i = 0; i (sizeof(dev_properties)/sizeof(struct dev_properties));
i++)
{
-if (strcmp(name, dev_properties[i].name) == 0)
+if (strcmp(name, dev_properties[i].name) == 0){
+if (dev_properties[i].type == None){
+ dev_properties[i].type =
+ MakeAtom(dev_properties[i].name,
+strlen(dev_properties[i].name),
+TRUE);
+ // Here we should probably die on failure.
+ // For now, leave it to the caller
+}
+
return dev_properties[i].type;
+}
}
return 0;
@@ -195,24 +205,6 @@ XIPropToFloat(XIPropertyValuePtr val, int *nelem_return,
float **buf_return)
return Success;
}
-/**
- * Init those properties that are allocated by the server and most likely used
- * by the DIX or the DDX.
- */
-void
-XIInitKnownProperties(void)
-{
-int i;
-for (i = 0; i (sizeof(dev_properties)/sizeof(struct dev_properties));
i++)
-{
-dev_properties[i].type =
-MakeAtom(dev_properties[i].name,
- strlen(dev_properties[i].name),
- TRUE);
-}
-}
-
-
/* Registers a new property handler on the given device and returns a unique
* identifier for this handler. This identifier is required to unregister the
* property handler again.
diff --git a/Xi/xiproperty.h b/Xi/xiproperty.h
index 12026e9..bf562b1 100644
--- a/Xi/xiproperty.h
+++ b/Xi/xiproperty.h
@@ -43,6 +43,4 @@ void SRepXListDeviceProperties(ClientPtr client, int size,
void SRepXGetDeviceProperty(ClientPtr client, int size,
xGetDevicePropertyReply *rep);
-void XIInitKnownProperties(void);
-
#endif /* XIPROPERTY_C */
--
1.6.0.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Compile error building xf86-input-keyboard from current git
Hi, I also have this problem and a little more digging in the code shows that: 1- XkbSetRulesDflts is defined in two different ways with one argument (in the file xkb/xkbInit.c) and 5 arguments in the proto definition. Fixing this is not problematic but I would like to know which definition I shall to take to modify the code (or just wait for the modifications to be done). 2- My guess is that the devs want to define XkbSetRulesDflts with one argument only but it means that the protos should be modified too. 3- this modification will break a couple of others things in the xserver source. A list of broken things dmx, xf86Config and Xi should be changed. best Mathieu Alan Coopersmith escribió: Alex Villacís Lasso wrote: Alan Coopersmith escribió: Alex Villacís Lasso wrote: kbd.c:154: error: 'XKB_DFLT_RULES' undeclared here (not in a function) This is from a recent git pulled this morning. I am pulling the changes from the last few hours, in the hope this is fixed by compiling an updated proto somewhere. The xorg-server.h file installed by the Xorg server build should define either __XKBDEFRULES__ (Xorg git prior to this week) or XKB_DFLT_RULES (current Xorg git). The kbd driver as of yesterday's git checkout should be accepting either one: #if !defined(XKB_DFLT_RULES) defined(__XKBDEFRULES__) # define XKB_DFLT_RULES __XKBDEFRULES__ #endif My build is not defining either. I am building with the util/modular/build.sh script included in the git tree. In the installation dir: [a...@srv64 xserver]$ grep -r __XKBDEFRULES__ include/ include/xorg/xorg-server.h:/* #undef __XKBDEFRULES__ */ [a...@srv64 xserver]$ grep -r XKB_DFLT_RULES include/ [a...@srv64 xserver]$ My xserver checkout is with current git master. I actually hadn't pushed the fix for that until shortly after sending that message yesterday (oops!) but git master now has: al...@alf:/export/alanc/X.org/mod/git/xserver [9:02am - 218] grep __XKBDEFRULES__ include/* al...@alf:/export/alanc/X.org/mod/git/xserver [9:02am - 219] grep XKB_DFLT_RULES include/* include/xkb-config.h.in:#undef XKB_DFLT_RULES include/xorg-server.h.in:#undef XKB_DFLT_RULES If you don't see XKB_DFLT_RULES at all, you're several days behind git master, or on a different branch than master. I updated xserver to current git. Now I am getting the same compile error in xserver itself as reported here: http://tinderbox.x.org/builds/2009-01-22-0007/logs/xserver/#build Keyboard.c: In function 'xnestKeyboardProc': Keyboard.c:177: warning: passing argument 1 of 'XkbSetRulesDflts' from incompatible pointer type Keyboard.c:177: error: too many arguments to function 'XkbSetRulesDflts' Keyboard.c:178: warning: implicit declaration of function 'XkbInitKeyboardDeviceStruct' Keyboard.c:178: warning: nested extern declaration of 'XkbInitKeyboardDeviceStruct' Keyboard.c:206: warning: passing argument 1 of 'InitKeyboardDeviceStruct' from incompatible pointer type Keyboard.c:206: warning: passing argument 2 of 'InitKeyboardDeviceStruct' from incompatible pointer type5B Keyboard.c:122: warning: unused variable 'j' Keyboard.c:117: warning: unused variable 'modifier_keymap' Keyboard.c: In function 'xnestUpdateModifierState': Keyboard.c:227: error: 'struct _KeyClassRec' has no member named 'state' Keyboard.c:235: error: 'struct _KeyClassRec' has no member named 'state' Keyboard.c:256: error: 'struct _KeyClassRec' has no member named 'state' -- Chris Ballc...@laptop.org ___ 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
[PATCH] Xvfb: Remove unused function GetLK201Mappings in InitInput.c
Silence a gcc warning. After commit 08363c5830bdea34012dcd954b45ccfdc79a3a7e
GetLK201Mappings is no longer needed.
Signed-off-by: Magnus Kessler magnus.kess...@gmx.net
diff --git a/hw/vfb/InitInput.c b/hw/vfb/InitInput.c
index e53ac4b..578cc49 100644
--- a/hw/vfb/InitInput.c
+++ b/hw/vfb/InitInput.c
@@ -61,201 +61,6 @@ void DDXRingBell(int volume, int pitch, int duration)
#define VFB_MAX_KEY 255
KeySym map[MAP_LENGTH * LK201_GLYPHS_PER_KEY];
-/* The only reason for using the LK201 mappings here was that they were
- * easy to lift.
- */
-static Bool
-GetLK201Mappings(KeySymsPtr pKeySyms, CARD8 *pModMap)
-{
-#define INDEX(in) ((in - VFB_MIN_KEY) * LK201_GLYPHS_PER_KEY)
-int i;
-
-for (i = 0; i MAP_LENGTH; i++)
- pModMap[i] = NoSymbol; /* make sure it is restored */
-pModMap[ KEY_LOCK ] = LockMask;
-pModMap[ KEY_SHIFT ] = ShiftMask;
-pModMap[ KEY_CTRL ] = ControlMask;
-pModMap[ KEY_COMPOSE ] = Mod1Mask;
-
-pKeySyms-minKeyCode = VFB_MIN_KEY;
-pKeySyms-maxKeyCode = VFB_MAX_KEY;
-pKeySyms-mapWidth = LK201_GLYPHS_PER_KEY;
-pKeySyms-map = map;
-
-for (i = 0; i (MAP_LENGTH * LK201_GLYPHS_PER_KEY); i++)
- map[i] = NoSymbol; /* make sure it is restored */
-
-map[INDEX(KEY_F1)] = XK_F1;
-map[INDEX(KEY_F2)] = XK_F2;
-map[INDEX(KEY_F3)] = XK_F3;
-map[INDEX(KEY_F4)] = XK_F4;
-map[INDEX(KEY_F5)] = XK_F5;
-map[INDEX(KEY_F6)] = XK_F6;
-map[INDEX(KEY_F7)] = XK_F7;
-map[INDEX(KEY_F8)] = XK_F8;
-map[INDEX(KEY_F9)] = XK_F9;
-map[INDEX(KEY_F10)] = XK_F10;
-map[INDEX(KEY_F11)] = XK_F11;
-map[INDEX(KEY_F12)] = XK_F12;
-map[INDEX(KEY_F13)] = XK_F13;
-map[INDEX(KEY_F14)] = XK_F14;
-
-map[INDEX(KEY_HELP)] = XK_Help;
-map[INDEX(KEY_MENU)] = XK_Menu;
-
-map[INDEX(KEY_F17)] = XK_F17;
-map[INDEX(KEY_F18)] = XK_F18;
-map[INDEX(KEY_F19)] = XK_F19;
-map[INDEX(KEY_F20)] = XK_F20;
-
-map[INDEX(KEY_FIND)] = XK_Find;
-map[INDEX(KEY_INSERT_HERE)] = XK_Insert;
-map[INDEX(KEY_REMOVE)] = XK_Delete;
-map[INDEX(KEY_SELECT)] = XK_Select;
-map[INDEX(KEY_PREV_SCREEN)] = XK_Prior;
-map[INDEX(KEY_NEXT_SCREEN)] = XK_Next;
-
-map[INDEX(KEY_KP_0)] = XK_KP_0;
-map[INDEX(KEY_KP_PERIOD)] = XK_KP_Decimal;
-map[INDEX(KEY_KP_ENTER)] = XK_KP_Enter;
-map[INDEX(KEY_KP_1)] = XK_KP_1;
-map[INDEX(KEY_KP_2)] = XK_KP_2;
-map[INDEX(KEY_KP_3)] = XK_KP_3;
-map[INDEX(KEY_KP_4)] = XK_KP_4;
-map[INDEX(KEY_KP_5)] = XK_KP_5;
-map[INDEX(KEY_KP_6)] = XK_KP_6;
-map[INDEX(KEY_KP_COMMA)] = XK_KP_Separator;
-map[INDEX(KEY_KP_7)] = XK_KP_7;
-map[INDEX(KEY_KP_8)] = XK_KP_8;
-map[INDEX(KEY_KP_9)] = XK_KP_9;
-map[INDEX(KEY_KP_HYPHEN)] = XK_KP_Subtract;
-map[INDEX(KEY_KP_PF1)] = XK_KP_F1;
-map[INDEX(KEY_KP_PF2)] = XK_KP_F2;
-map[INDEX(KEY_KP_PF3)] = XK_KP_F3;
-map[INDEX(KEY_KP_PF4)] = XK_KP_F4;
-
-map[INDEX(KEY_LEFT)] = XK_Left;
-map[INDEX(KEY_RIGHT)] = XK_Right;
-map[INDEX(KEY_DOWN)] = XK_Down;
-map[INDEX(KEY_UP)] = XK_Up;
-
-map[INDEX(KEY_SHIFT)] = XK_Shift_L;
-map[INDEX(KEY_CTRL)] = XK_Control_L;
-map[INDEX(KEY_LOCK)] = XK_Caps_Lock;
-map[INDEX(KEY_COMPOSE)] = XK_Multi_key;
-map[INDEX(KEY_COMPOSE)+1] = XK_Meta_L;
-map[INDEX(KEY_DELETE)] = XK_Delete;
-map[INDEX(KEY_RETURN)] = XK_Return;
-map[INDEX(KEY_TAB)] = XK_Tab;
-
-map[INDEX(KEY_TILDE)] = XK_quoteleft;
-map[INDEX(KEY_TILDE)+1] = XK_asciitilde;
-
-map[INDEX(KEY_TR_1)] = XK_1;
-map[INDEX(KEY_TR_1)+1] = XK_exclam;
-map[INDEX(KEY_Q)] = XK_Q;
-map[INDEX(KEY_A)] = XK_A;
-map[INDEX(KEY_Z)] = XK_Z;
-
-map[INDEX(KEY_TR_2)] = XK_2;
-map[INDEX(KEY_TR_2)+1] = XK_at;
-
-map[INDEX(KEY_W)] = XK_W;
-map[INDEX(KEY_S)] = XK_S;
-map[INDEX(KEY_X)] = XK_X;
-
-map[INDEX(KEY_LANGLE_RANGLE)] = XK_less;
-map[INDEX(KEY_LANGLE_RANGLE)+1] = XK_greater;
-
-map[INDEX(KEY_TR_3)] = XK_3;
-map[INDEX(KEY_TR_3)+1] = XK_numbersign;
-
-map[INDEX(KEY_E)] = XK_E;
-map[INDEX(KEY_D)] = XK_D;
-map[INDEX(KEY_C)] = XK_C;
-
-map[INDEX(KEY_TR_4)] = XK_4;
-map[INDEX(KEY_TR_4)+1] = XK_dollar;
-
-map[INDEX(KEY_R)] = XK_R;
-map[INDEX(KEY_F)] = XK_F;
-map[INDEX(KEY_V)] = XK_V;
-map[INDEX(KEY_SPACE)] = XK_space;
-
-map[INDEX(KEY_TR_5)] = XK_5;
-map[INDEX(KEY_TR_5)+1] = XK_percent;
-
-map[INDEX(KEY_T)] = XK_T;
-map[INDEX(KEY_G)] = XK_G;
-map[INDEX(KEY_B)] = XK_B;
-
-map[INDEX(KEY_TR_6)] = XK_6;
-map[INDEX(KEY_TR_6)+1] = XK_asciicircum;
-
-map[INDEX(KEY_Y)] = XK_Y;
-map[INDEX(KEY_H)] = XK_H;
-map[INDEX(KEY_N)] = XK_N;
-
-map[INDEX(KEY_TR_7)] = XK_7;
-map[INDEX(KEY_TR_7)+1] = XK_ampersand;
-
-map[INDEX(KEY_U)] = XK_U;
-map[INDEX(KEY_J)] = XK_J;
-map[INDEX(KEY_M)] = XK_M;
-
-map[INDEX(KEY_TR_8)] = XK_8;
-map[INDEX(KEY_TR_8)+1] = XK_asterisk;
-
-map[INDEX(KEY_I)] = XK_I;
-map[INDEX(KEY_K)] = XK_K;
-
-
[PATCH] Xvfb: add missing include for new xkbsrv.h
Commit 08363c5830bdea34012dcd954b45ccfdc79a3a7e added call to XkbGetRulesDflts defined in xkbsrv.h Signed-off-by: Magnus Kessler magnus.kess...@gmx.net --- hw/vfb/InitInput.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/vfb/InitInput.c b/hw/vfb/InitInput.c index 578cc49..aa90252 100644 --- a/hw/vfb/InitInput.c +++ b/hw/vfb/InitInput.c @@ -39,6 +39,7 @@ from The Open Group. #include mibstore.h #include mipointer.h #include lk201kbd.h +#include xkbsrv.h #include X11/keysym.h Bool -- 1.6.1 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: newest drivers lose X-video support?
On Fri, Jan 23, 2009 at 00:33:10 -0800, Brandon Kuczenski wrote: Hello, I recently installed updated versions of xserver-xorg-video-intel (2.5.1-1ubuntu5), libdrm2 and libdrm-intel1 (2.4.1-0ubuntu7) in order to try to resolve a suspend-to-RAM bug. I installed files from this archive: https://edge.launchpad.net/~intel-gfx-testing/+archive The fix appears to have worked, but an apparent side-effect is that I have lost X-video support. xvinfo returns: $ xvinfo X-Video Extension version 2.2 screen #0 no adaptors present In the past, Ubuntu patched the Intel driver to disable textured video. If your hardware doesn't support video overlay anymore, you would end up without any XV adaptor at all. What hardware are you using? Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] .gitignore: ignore sdksyms.dep
Signed-off-by: Magnus Kessler magnus.kess...@gmx.net diff --git a/.gitignore b/.gitignore index bd38ddb..4d277d9 100644 --- a/.gitignore +++ b/.gitignore @@ -150,3 +150,4 @@ include/xkb-config.h include/xorg-config.h include/xorg-server.h include/xwin-config.h +sdksyms.dep -- 1.6.1 signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Random xrandr behaviour
With uptodate git versions of xrandr, xserver, mesa and the intel driver I observe a random behaviour of xrandr. In the same session the output of xrandr randomly switches between $ xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096 VGA connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm 1280x1024 60.0*+ 75.0 60.0* 1152x864 75.0 1024x768 75.0 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x48075.0 72.8 66.7 59.9 720x40070.1 and $ xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096 VGA disconnected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm 1280x1024 (0x3c) 108.0MHz h: width 1280 start 1328 end 1440 total 1688 skew0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz I also observe a more or less pronounced flickering of the screen when xrandr is run. I wonder if the observed behaviour may have the same root cause as the crashes observed with SDL applications when they try to obtain mode lines [0] [1]. Can someone please advise how I could track down this issue further? Regards, Magnus Kessler [0] http://bugs.freedesktop.org/show_bug.cgi?id=17431 [1] http://bugs.freedesktop.org/show_bug.cgi?id=13952 signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Additional pci-id for the nv driver
Dear Aaron,
I've noticed that the nv driver is not automatically chosen for my Geforce
7300 GT unless I don't specify the nv driver in the xorg.conf.
The attached patch solves the problem.
Regards,
Alberto Milone
# On branch master
# Changes to be committed:
#
# modified: src/nv_driver.c
# * Add a pci-id for GeForce 7300 GT
#
diff --git a/src/nv_driver.c b/src/nv_driver.c
index faf73a9..f9e47d9 100644
--- a/src/nv_driver.c
+++ b/src/nv_driver.c
@@ -333,6 +333,7 @@ static SymTabRec NVKnownChipsets[] =
{ 0x10DE01DD, GeForce 7500 LE },
{ 0x10DE01DE, Quadro FX 350 },
{ 0x10DE01DF, GeForce 7300 GS },
+ { 0x10DE02E2, GeForce 7300 GT },
{ 0x10DE0391, GeForce 7600 GT },
{ 0x10DE0392, GeForce 7600 GS },
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Additional pci-id for the nv driver
On Fri, 2009-01-23 at 09:16 -0800, Alberto Milone wrote: Dear Aaron, I've noticed that the nv driver is not automatically chosen for my Geforce 7300 GT unless I don't specify the nv driver in the xorg.conf. Sorry, now that I look at it some more, something else must be wrong. The 0x2E2 device ID should have hit the NVGetPCIXpressChip case in NVPciProbe: const CARD32 id = ((dev-device_id 0xfff0) == 0x00F0 || (dev-device_id 0xfff0) == 0x02E0) ? NVGetPCIXpressChip(dev) : dev-vendor_id 16 | dev-device_id; and come up with 0x0393. Can you please put a breakpoint there and see what went wrong? -- Aaron --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] : quirk for AOpen MP45
On 2009.01.18 19:46:16 +0800, Vincent Mussard wrote: Zhenyu Wang wrote : 2.6-branch doesn't have my LVDS detect patch, as I'd like to get more testing before putting in stable. Could you try git master to see if LVDS has the right detection? I know some Aopen might still not work, so that we can use your quirk. Hi Just tried current git master of xf86-video-intel (git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel) and got the same LVDS detection although I don't have one. Please find attached the xrandr output. I don't have a xorg.conf and without my patch resolution is automatically set to 1024x768 because of the LVDS output. With the patch resolution is correctly set to 1920x1200 (on my 24 display). Pushed. Thanks! -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: build failure in xserver-master (2009-01-23 03:11:15)
2009/1/23 Joe Smith stop...@yahoo.com: (If someone has already reported this, sorry.) Background: I hacked together an improved(?) install script based on the script found at http://www.x.org/wiki/Development/git. It's attached so these results can be repeated. (Sorry, I'm still learning bash) I also downloaded the latest tagged release of everything via Firefox, since I haven't figured out how to tell git to do it (b/c cloning the latest repository version is often too unstable). I've attached a source listing so you can see the versions I used for this run. The install script is invoked the same as expected: init, then build. I am redirecting all output to two files, named init and build, of course. Problem: In the build output file (intel_install_BUILD_090123-16:36.txt), you can see the following error at the end when compiling xserver-master: Keyboard.c: In function 'xnestUpdateModifierState': Keyboard.c:227: error: 'struct _KeyClassRec' has no member named 'state' Keyboard.c:235: error: 'struct _KeyClassRec' has no member named 'state' Keyboard.c:256: error: 'struct _KeyClassRec' has no member named 'state' make[3]: *** [Keyboard.o] Error 1 Hopefully the attached install script will allow the author to reproduce this error. There was just a ton of churn on the XKB code, so it might be a little bit until everything is back in order. For now, you might try building the server with --disable-xnest, but I think you may hit similar issues with xorg (although I haven't tried myself). If you can't get xorg to build, you might try backing up 15 commits or so. Building server-1.6-branch is a possibility, too, since this just affects master. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Xi: define a default range of axis labels.
On Mon, 2009-01-19 at 23:23 +1100, Peter Hutterer wrote:
ATM, we are able to announce that a device has multiple axes, but clients have
to take educated guesses as to wether axis N is tilt, pressure, pan or
bananas. This patch introduces a set of default properties, initialized by the
server on init. Drivers can then take the AXIS_LABEL_PROP and fill it with the
matching labels to indicate to the client which axis does what. Clients can
query this property and adjust their user interface accordingly.
The range of labels is taken from linux/input.h, presumably that's the ones at
least the Linux kernel can give us for a device.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/xiproperty.c | 39 -
include/xserver-properties.h | 49
++
2 files changed, 87 insertions(+), 1 deletions(-)
diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index 53b2f6a..3bc2818 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -54,7 +54,44 @@ static struct dev_properties
{0, ACCEL_PROP_PROFILE_NUMBER},
{0, ACCEL_PROP_CONSTANT_DECELERATION},
{0, ACCEL_PROP_ADAPTIVE_DECELERATION},
-{0, ACCEL_PROP_VELOCITY_SCALING}
+{0, ACCEL_PROP_VELOCITY_SCALING},
+{0, AXIS_LABEL_PROP},
+{0, AXIS_LABEL_PROP_REL_X},
+{0, AXIS_LABEL_PROP_REL_Y},
+{0, AXIS_LABEL_PROP_REL_Z},
+{0, AXIS_LABEL_PROP_REL_RX},
+{0, AXIS_LABEL_PROP_REL_RY},
+{0, AXIS_LABEL_PROP_REL_RZ},
+{0, AXIS_LABEL_PROP_REL_HWHEEL},
+{0, AXIS_LABEL_PROP_REL_DIAL},
+{0, AXIS_LABEL_PROP_REL_WHEEL},
+{0, AXIS_LABEL_PROP_REL_MISC},
+{0, AXIS_LABEL_PROP_ABS_X},
+{0, AXIS_LABEL_PROP_ABS_Y},
+{0, AXIS_LABEL_PROP_ABS_Z},
+{0, AXIS_LABEL_PROP_ABS_RX},
+{0, AXIS_LABEL_PROP_ABS_RY},
+{0, AXIS_LABEL_PROP_ABS_RZ},
+{0, AXIS_LABEL_PROP_ABS_THROTTLE},
+{0, AXIS_LABEL_PROP_ABS_RUDDER},
+{0, AXIS_LABEL_PROP_ABS_WHEEL},
+{0, AXIS_LABEL_PROP_ABS_GAS},
+{0, AXIS_LABEL_PROP_ABS_BRAKE},
+{0, AXIS_LABEL_PROP_ABS_HAT0X},
+{0, AXIS_LABEL_PROP_ABS_HAT0Y},
+{0, AXIS_LABEL_PROP_ABS_HAT1X},
+{0, AXIS_LABEL_PROP_ABS_HAT1Y},
+{0, AXIS_LABEL_PROP_ABS_HAT2X},
+{0, AXIS_LABEL_PROP_ABS_HAT2Y},
+{0, AXIS_LABEL_PROP_ABS_HAT3X},
+{0, AXIS_LABEL_PROP_ABS_HAT3Y},
+{0, AXIS_LABEL_PROP_ABS_PRESSURE},
+{0, AXIS_LABEL_PROP_ABS_DISTANCE},
+{0, AXIS_LABEL_PROP_ABS_TILT_X},
+{0, AXIS_LABEL_PROP_ABS_TILT_Y},
+{0, AXIS_LABEL_PROP_ABS_TOOL_WIDTH},
+{0, AXIS_LABEL_PROP_ABS_VOLUME},
+{0, AXIS_LABEL_PROP_ABS_MISC}
};
static long XIPropHandlerID = 1;
diff --git a/include/xserver-properties.h b/include/xserver-properties.h
index 1327e59..1ce37c5 100644
--- a/include/xserver-properties.h
+++ b/include/xserver-properties.h
@@ -43,4 +43,53 @@
/* FLOAT, format 32 */
#define ACCEL_PROP_VELOCITY_SCALING Device Accel Velocity Scaling
+
+/* Axis labels */
+/* ATOM values, ideally one per axis */
+#define AXIS_LABEL_PROP Axis Labels
+
+/* The following are for use in AXIS_LABEL_PROP only and do not have a
+ * defined value that is parsed by the server. */
+#define AXIS_LABEL_PROP_REL_X Rel X
+#define AXIS_LABEL_PROP_REL_Y Rel Y
+#define AXIS_LABEL_PROP_REL_Z Rel Z
+#define AXIS_LABEL_PROP_REL_RX Rel Rotary X
+#define AXIS_LABEL_PROP_REL_RY Rel Rotary Y
+#define AXIS_LABEL_PROP_REL_RZ Rel Rotary Z
+#define AXIS_LABEL_PROP_REL_HWHEEL Rel Horiz Wheel
+#define AXIS_LABEL_PROP_REL_DIALRel Dial
+#define AXIS_LABEL_PROP_REL_WHEEL Rel Vert Wheel
+#define AXIS_LABEL_PROP_REL_MISCRel Misc
+
+/*
+ * Absolute axes
+ */
+
+#define AXIS_LABEL_PROP_ABS_X Abs X
+#define AXIS_LABEL_PROP_ABS_Y Abs Y
+#define AXIS_LABEL_PROP_ABS_Z Abs Z
+#define AXIS_LABEL_PROP_ABS_RX Abs Rotary X
+#define AXIS_LABEL_PROP_ABS_RY Abs Rotary Y
+#define AXIS_LABEL_PROP_ABS_RZ Abs Rotary Z
+#define AXIS_LABEL_PROP_ABS_THROTTLEAbs Throttle
+#define AXIS_LABEL_PROP_ABS_RUDDER Abs Rudder
+#define AXIS_LABEL_PROP_ABS_WHEEL Abs Wheel
+#define AXIS_LABEL_PROP_ABS_GAS Abs Gas
+#define AXIS_LABEL_PROP_ABS_BRAKE Abs Brake
+#define AXIS_LABEL_PROP_ABS_HAT0X Abs Hat 0 X
+#define AXIS_LABEL_PROP_ABS_HAT0Y Abs Hat 0 Y
+#define AXIS_LABEL_PROP_ABS_HAT1X Abs Hat 1 X
+#define AXIS_LABEL_PROP_ABS_HAT1Y Abs Hat 1 Y
+#define AXIS_LABEL_PROP_ABS_HAT2X Abs Hat 2 X
+#define AXIS_LABEL_PROP_ABS_HAT2Y Abs Hat 2 Y
+#define AXIS_LABEL_PROP_ABS_HAT3X Abs Hat 3 X
+#define AXIS_LABEL_PROP_ABS_HAT3Y Abs Hat 3 Y
+#define AXIS_LABEL_PROP_ABS_PRESSUREAbs Pressure
+#define AXIS_LABEL_PROP_ABS_DISTANCEAbs Distance
+#define AXIS_LABEL_PROP_ABS_TILT_X Abs Tilt X
+#define AXIS_LABEL_PROP_ABS_TILT_Y
