[PATCH] xf86-input-void: Fix build against XINPUT ABI 5
---
untested.
src/void.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/void.c b/src/void.c
index a5a47be..00aeb52 100644
--- a/src/void.c
+++ b/src/void.c
@@ -202,10 +202,22 @@ xf86VoidControlProc(DeviceIntPtr device, int what)
return !Success;
}
*/
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 5
+{
+XkbRMLVOSet rmlvo;
+XkbGetRulesDflts(&rmlvo);
+if (!InitKeyboardDeviceStruct(device, &rmlvo, BellProc,
KeyControlProc))
+{
+ErrorF("unable to init keyboard device\n");
+return !Success;
+}
+}
+#else
if (InitKeyboardDeviceStruct((DevicePtr)device, &void_keysyms, NULL,
BellProc, KeyControlProc) == FALSE) {
ErrorF("unable to init keyboard device\n");
return !Success;
}
+#endif
if (InitValuatorClassDeviceStruct(device,
2,
--
1.6.0.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Driver updates/releases needed for Xorg 1.6 release
Alan Coopersmith wrote: > I dropped 1.5.99.901 into our build system that's currently building > 1.5.3 and the latest driver releases okay, and got failures in many > of the driver builds - most of these appear to be fixed in git, just > need tarballs released, while one or two may still need some code changes. I switched all the drivers I listed to build from git master, and after the updates I pushed to drop the XFree86 3 vs. 4 #ifdefs from the summa driver, they all build. None are tested, but just building is all we've checked for many of them for prior releases. -- -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: Recent input changes
Alan Coopersmith wrote: > Jeff Chua wrote: >> On Sun, Jan 25, 2009 at 4:55 AM, Joel Feiner wrote: >>> xf86-input-keyboard also doesn't build with similar errors: kbd.c:567: warning: passing argument 1 of 'InitKeyboardDeviceStruct' from incompatible pointer type kbd.c:567: warning: passing argument 2 of 'InitKeyboardDeviceStruct' from incompatible pointer type kbd.c:567: warning: passing argument 3 of 'InitKeyboardDeviceStruct' from incompatible pointer type kbd.c:567: warning: passing argument 4 of 'InitKeyboardDeviceStruct' from incompatible pointer type kbd.c:567: error: too many arguments to function 'InitKeyboardDeviceStruct' kbd.c: In function 'PostKbdEvent': kbd.c:699: error: 'KeyClassRec' has no member named 'state' kbd.c:702: error: 'KeyClassRec' has no member named 'state' kbd.c:714: error: 'KeyClassRec' has no member named 'state' kbd.c:726: error: 'KeyClassRec' has no member named 'curKeySyms' kbd.c:727: error: 'KeyClassRec' has no member named 'curKeySyms' kbd.c:728: error: 'KeyClassRec' has no member named 'curKeySyms' kbd.c:791: error: 'KeyClassRec' has no member named 'modifierMap' kbd.c:847: error: 'KeyClassRec' has no member named 'modifierMap' kbd.c:854: error: 'KeyClassRec' has no member named 'modifierKeyMap' kbd.c:854: error: 'KeyClassRec' has no member named 'maxKeysPerModifier' kbd.c:857: error: 'KeyClassRec' has no member named 'modifierKeyMap' kbd.c:857: error: 'KeyClassRec' has no member named 'maxKeysPerModifier' kbd.c: At top level: kbd.c:863: warning: 'ModuleInfoRec' is deprecated >> >> Any fix for this? I've tried the latest xserver. Compile fine. But >> xf86-input-keyboard still failed to compiled. Have tried with >> --disable-xnest, but still failed. > > You might try applying > http://people.freedesktop.org/~daniels/kbd-pass-the-absinthe.diff > but that's probably no more tested than the other recent XKB changes. I just made a somewhat simpler version, that from some basic tests only misses autorepeat, but I did not follow the code to see how to actually set the repeat and intervals. Maybe should be on the KeybdCtrl defaultKeyboardControl, as I don't know if there is an api for calling it..., but would look ugly to set that global variable, so, left as an exercise to whoever wants to finish the patch; I am using evdev... Hint on how I did test the patch, and some intermediate versions that would fail to load due to unresolved symbols; add to /etc/X11/xorg.conf something like: -%<- Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "ExplorerPS/2" Option "Device" "/dev/input/mice" EndSection Section "InputDevice" Identifier "Keyboard1" Driver "kbd" Option "CoreKeyboard" EndSection -%<- and to Section "ServerLayout": -%<- InputDevice "Keyboard1" "CoreKeyboard" InputDevice "Mouse1" "CorePointer" -%<- and to Section "ServerFlags": -%<- Option "AutoEnableDevices" "True" Option "AutoAddDevices" "False" -%<- Then, run something like: % startx & sleep 15; killall X If you have a ssh access, it will be easier... Then, you may also need to run from a xterm something like: % setxkbmap -rules xorg us_intl Paulo xf86-input-keyboard-git-master.patch Description: Binary data ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] dix: Use GenericEvent instead of LASTEvent to check for core events.
---
dix/events.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dix/events.c b/dix/events.c
index 17e7142..0c8d198 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -3256,7 +3256,7 @@ CheckPassiveGrabsOnWindow(
tempGrab.modifierDevice = grab->modifierDevice;
tempGrab.modifiersDetail.exact = xkbi ? xkbi->state.grab_mods : 0;
/* ignore the device for core events when comparing grabs */
- if (GrabMatchesSecond(&tempGrab, grab, (xE->u.u.type < LASTEvent)) &&
+ if (GrabMatchesSecond(&tempGrab, grab, (xE->u.u.type < GenericEvent)) &&
(!grab->confineTo ||
(grab->confineTo->realized &&
BorderSizeNotEmpty(device, grab->confineTo
@@ -3271,7 +3271,7 @@ CheckPassiveGrabsOnWindow(
Since XGrabDeviceButton requires to specify the
modifierDevice explicitly, we don't override this choice.
*/
-if (xE->u.u.type < LASTEvent)
+if (xE->u.u.type < GenericEvent)
{
grab->device = device;
grab->modifierDevice = GetPairedDevice(device);
--
1.6.0.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Xext: rename saver's EventType to SaverEventType.
Avoid namespace clashing with the internal events.
---
Xext/saver.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Xext/saver.c b/Xext/saver.c
index 3aaec34..cd67749 100644
--- a/Xext/saver.c
+++ b/Xext/saver.c
@@ -142,7 +142,7 @@ static int ScreenSaverFreeSuspend(
* entry from the per-screen queue.
*/
-static RESTYPE EventType; /* resource type for event masks */
+static RESTYPE SaverEventType; /* resource type for event masks */
typedef struct _ScreenSaverEvent *ScreenSaverEventPtr;
@@ -253,7 +253,7 @@ ScreenSaverExtensionInit(INITARGS)
ScreenPtr pScreen;
AttrType = CreateNewResourceType(ScreenSaverFreeAttr);
-EventType = CreateNewResourceType(ScreenSaverFreeEvents);
+SaverEventType = CreateNewResourceType(ScreenSaverFreeEvents);
SuspendType = CreateNewResourceType(ScreenSaverFreeSuspend);
for (i = 0; i < screenInfo.numScreens; i++)
@@ -261,7 +261,7 @@ ScreenSaverExtensionInit(INITARGS)
pScreen = screenInfo.screens[i];
SetScreenPrivate (pScreen, NULL);
}
-if (AttrType && EventType && SuspendType &&
+if (AttrType && SaverEventType && SuspendType &&
(extEntry = AddExtension(ScreenSaverName, ScreenSaverNumberEvents, 0,
ProcScreenSaverDispatch,
SProcScreenSaverDispatch,
NULL, StandardMinorOpcode)))
@@ -339,7 +339,7 @@ setEventMask (ScreenPtr pScreen, ClientPtr client, unsigned
long mask)
break;
if (mask == 0)
{
- FreeResource (pEv->resource, EventType);
+ FreeResource (pEv->resource, SaverEventType);
*pPrev = pEv->next;
xfree (pEv);
CheckScreenPrivate (pScreen);
@@ -359,7 +359,7 @@ setEventMask (ScreenPtr pScreen, ClientPtr client, unsigned
long mask)
pEv->client = client;
pEv->screen = pScreen;
pEv->resource = FakeClientID (client->index);
- if (!AddResource (pEv->resource, EventType, (pointer) pEv))
+ if (!AddResource (pEv->resource, SaverEventType, (pointer) pEv))
return FALSE;
}
pEv->mask = mask;
--
1.6.0.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Xext: rename shape's EventType to ShapeEventType to avoid name clashing.
---
Xext/shape.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Xext/shape.c b/Xext/shape.c
index 8827a02..cb05707 100644
--- a/Xext/shape.c
+++ b/Xext/shape.c
@@ -95,7 +95,7 @@ static DISPATCH_PROC(SProcShapeSelectInput);
#endif
static int ShapeEventBase = 0;
-static RESTYPE ClientType, EventType; /* resource types for event masks */
+static RESTYPE ClientType, ShapeEventType; /* resource types for event masks */
/*
* each window has a list of clients requesting
@@ -128,8 +128,8 @@ ShapeExtensionInit(void)
ExtensionEntry *extEntry;
ClientType = CreateNewResourceType(ShapeFreeClient);
-EventType = CreateNewResourceType(ShapeFreeEvents);
-if (ClientType && EventType &&
+ShapeEventType = CreateNewResourceType(ShapeFreeEvents);
+if (ClientType && ShapeEventType &&
(extEntry = AddExtension(SHAPENAME, ShapeNumberEvents, 0,
ProcShapeDispatch, SProcShapeDispatch,
NULL, StandardMinorOpcode)))
@@ -741,7 +741,7 @@ ShapeFreeClient (pointer data, XID id)
pShapeEvent = (ShapeEventPtr) data;
pWin = pShapeEvent->window;
-pHead = (ShapeEventPtr *) LookupIDByType(pWin->drawable.id, EventType);
+pHead = (ShapeEventPtr *) LookupIDByType(pWin->drawable.id,
ShapeEventType);
if (pHead) {
pPrev = 0;
for (pCur = *pHead; pCur && pCur != pShapeEvent; pCur=pCur->next)
@@ -788,7 +788,7 @@ ProcShapeSelectInput (ClientPtr client)
if (rc != Success)
return rc;
pHead = (ShapeEventPtr *)SecurityLookupIDByType(client,
- pWin->drawable.id, EventType, DixWriteAccess);
+ pWin->drawable.id, ShapeEventType, DixWriteAccess);
switch (stuff->enable) {
case xTrue:
if (pHead) {
@@ -828,7 +828,7 @@ ProcShapeSelectInput (ClientPtr client)
{
pHead = xalloc (sizeof (ShapeEventPtr));
if (!pHead ||
- !AddResource (pWin->drawable.id, EventType, (pointer)pHead))
+ !AddResource (pWin->drawable.id, ShapeEventType,
(pointer)pHead))
{
FreeResource (clientResource, RT_NONE);
return BadAlloc;
@@ -878,7 +878,7 @@ SendShapeNotify (WindowPtr pWin, int which)
RegionPtr region;
BYTE shaped;
-pHead = (ShapeEventPtr *) LookupIDByType(pWin->drawable.id, EventType);
+pHead = (ShapeEventPtr *) LookupIDByType(pWin->drawable.id,
ShapeEventType);
if (!pHead)
return;
switch (which) {
@@ -957,7 +957,7 @@ ProcShapeInputSelected (ClientPtr client)
if (rc != Success)
return rc;
pHead = (ShapeEventPtr *) SecurityLookupIDByType(client,
- pWin->drawable.id, EventType, DixReadAccess);
+ pWin->drawable.id, ShapeEventType, DixReadAccess);
enabled = xFalse;
if (pHead) {
for (pShapeEvent = *pHead;
--
1.6.0.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] dix: add SetBit(arr, bit) and ClearBit(arr, bit) to include/inputstr.h
--- include/inputstr.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/inputstr.h b/include/inputstr.h index 2ee4f9b..2b6de02 100644 --- a/include/inputstr.h +++ b/include/inputstr.h @@ -57,6 +57,8 @@ SOFTWARE. #include "privates.h" #define BitIsOn(ptr, bit) (((BYTE *) (ptr))[(bit)>>3] & (1 << ((bit) & 7))) +#define SetBit(ptr, bit) (((BYTE *) (ptr))[(bit)>>3] |= (1 << ((bit) & 7))) +#define ClearBit(ptr, bit) (((BYTE *)(ptr))[(bit)>>3] &= ~(1 << ((bit) & 7))) #define SameClient(obj,client) \ (CLIENT_BITS((obj)->resource) == (client)->clientAsMask) -- 1.6.0.6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] render: rename SetBit to RenderSetBit.
Avoiding namespace collision with the SetBit macro soon to be used in the
input code.
---
render/render.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/render/render.c b/render/render.c
index b6e9567..658b170 100644
--- a/render/render.c
+++ b/render/render.c
@@ -1505,7 +1505,7 @@ ProcRenderFillRectangles (ClientPtr client)
}
static void
-SetBit (unsigned char *line, int x, int bit)
+RenderSetBit (unsigned char *line, int x, int bit)
{
unsigned char mask;
@@ -1676,8 +1676,8 @@ ProcRenderCreateCursor (ClientPtr client)
{
CARD32 a = ((p >> 24));
- SetBit (mskline, x, a != 0);
- SetBit (srcline, x, a != 0 && p == twocolor[0]);
+ RenderSetBit (mskline, x, a != 0);
+ RenderSetBit (srcline, x, a != 0 && p == twocolor[0]);
}
else
{
@@ -1685,9 +1685,9 @@ ProcRenderCreateCursor (ClientPtr client)
CARD32 i = ((CvtR8G8B8toY15(p) >> 7) * DITHER_SIZE + 127) /
255;
CARD32 d = orderedDither[y&(DITHER_DIM-1)][x&(DITHER_DIM-1)];
/* Set mask from dithered alpha value */
- SetBit(mskline, x, a > d);
+ RenderSetBit(mskline, x, a > d);
/* Set src from dithered intensity value */
- SetBit(srcline, x, a > d && i <= d);
+ RenderSetBit(srcline, x, a > d && i <= d);
}
}
srcline += stride;
--
1.6.0.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] include: remove now-unused sempahore macros.
Obsolete with the new enter/leave model. --- include/input.h | 15 --- 1 files changed, 0 insertions(+), 15 deletions(-) diff --git a/include/input.h b/include/input.h index bf826b0..3b7a173 100644 --- a/include/input.h +++ b/include/input.h @@ -95,21 +95,6 @@ SOFTWARE. #define RevertToFollowKeyboard 3 #endif -/* Used for enter/leave and focus in/out semaphores */ -#define SEMAPHORE_FIELD_SET(win, dev, field) \ -(win)->field[(dev)->id/8] |= (1 << ((dev)->id % 8)); \ - -#define SEMAPHORE_FIELD_UNSET(win, dev, field) \ -(win)->field[(dev)->id/8] &= ~(1 << ((dev)->id % 8)); - -#define FOCUS_SEMAPHORE_SET(win, dev) \ -SEMAPHORE_FIELD_SET(win, dev, focusinout); - -#define FOCUS_SEMAPHORE_UNSET(win, dev) \ -SEMAPHORE_FIELD_UNSET(win, dev, focusinout); - -#define FOCUS_SEMAPHORE_ISSET(win, dev) \ -(win)->focusinout[(dev)->id/8] & (1 << ((dev)->id % 8)) typedef unsigned long Leds; typedef struct _OtherClients *OtherClientsPtr; -- 1.6.0.6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 0/6] Cleanup patches in preparation for internal events.
I'm currently working on switching the server over from using the wire-format events inside the event generation/processing cycle to use custom structs, only visible inside the server. More on that later, but here's a couple of cleanup patches that can go into master already. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Recent input changes
Jeff Chua wrote: > On Sun, Jan 25, 2009 at 4:55 AM, Joel Feiner wrote: >> xf86-input-keyboard also doesn't build with similar errors: >>> kbd.c:567: warning: passing argument 1 of 'InitKeyboardDeviceStruct' from >>> incompatible pointer type >>> kbd.c:567: warning: passing argument 2 of 'InitKeyboardDeviceStruct' from >>> incompatible pointer type >>> kbd.c:567: warning: passing argument 3 of 'InitKeyboardDeviceStruct' from >>> incompatible pointer type >>> kbd.c:567: warning: passing argument 4 of 'InitKeyboardDeviceStruct' from >>> incompatible pointer type >>> kbd.c:567: error: too many arguments to function 'InitKeyboardDeviceStruct' >>> kbd.c: In function 'PostKbdEvent': >>> kbd.c:699: error: 'KeyClassRec' has no member named 'state' >>> kbd.c:702: error: 'KeyClassRec' has no member named 'state' >>> kbd.c:714: error: 'KeyClassRec' has no member named 'state' >>> kbd.c:726: error: 'KeyClassRec' has no member named 'curKeySyms' >>> kbd.c:727: error: 'KeyClassRec' has no member named 'curKeySyms' >>> kbd.c:728: error: 'KeyClassRec' has no member named 'curKeySyms' >>> kbd.c:791: error: 'KeyClassRec' has no member named 'modifierMap' >>> kbd.c:847: error: 'KeyClassRec' has no member named 'modifierMap' >>> kbd.c:854: error: 'KeyClassRec' has no member named 'modifierKeyMap' >>> kbd.c:854: error: 'KeyClassRec' has no member named 'maxKeysPerModifier' >>> kbd.c:857: error: 'KeyClassRec' has no member named 'modifierKeyMap' >>> kbd.c:857: error: 'KeyClassRec' has no member named 'maxKeysPerModifier' >>> kbd.c: At top level: >>> kbd.c:863: warning: 'ModuleInfoRec' is deprecated > > Any fix for this? I've tried the latest xserver. Compile fine. But > xf86-input-keyboard still failed to compiled. Have tried with > --disable-xnest, but still failed. You might try applying http://people.freedesktop.org/~daniels/kbd-pass-the-absinthe.diff but that's probably no more tested than the other recent XKB changes. -- -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: Recent input changes
On Sun, Jan 25, 2009 at 4:55 AM, Joel Feiner wrote: > xf86-input-keyboard also doesn't build with similar errors: >> kbd.c:567: warning: passing argument 1 of 'InitKeyboardDeviceStruct' from >> incompatible pointer type >> kbd.c:567: warning: passing argument 2 of 'InitKeyboardDeviceStruct' from >> incompatible pointer type >> kbd.c:567: warning: passing argument 3 of 'InitKeyboardDeviceStruct' from >> incompatible pointer type >> kbd.c:567: warning: passing argument 4 of 'InitKeyboardDeviceStruct' from >> incompatible pointer type >> kbd.c:567: error: too many arguments to function 'InitKeyboardDeviceStruct' >> kbd.c: In function 'PostKbdEvent': >> kbd.c:699: error: 'KeyClassRec' has no member named 'state' >> kbd.c:702: error: 'KeyClassRec' has no member named 'state' >> kbd.c:714: error: 'KeyClassRec' has no member named 'state' >> kbd.c:726: error: 'KeyClassRec' has no member named 'curKeySyms' >> kbd.c:727: error: 'KeyClassRec' has no member named 'curKeySyms' >> kbd.c:728: error: 'KeyClassRec' has no member named 'curKeySyms' >> kbd.c:791: error: 'KeyClassRec' has no member named 'modifierMap' >> kbd.c:847: error: 'KeyClassRec' has no member named 'modifierMap' >> kbd.c:854: error: 'KeyClassRec' has no member named 'modifierKeyMap' >> kbd.c:854: error: 'KeyClassRec' has no member named 'maxKeysPerModifier' >> kbd.c:857: error: 'KeyClassRec' has no member named 'modifierKeyMap' >> kbd.c:857: error: 'KeyClassRec' has no member named 'maxKeysPerModifier' >> kbd.c: At top level: >> kbd.c:863: warning: 'ModuleInfoRec' is deprecated Any fix for this? I've tried the latest xserver. Compile fine. But xf86-input-keyboard still failed to compiled. Have tried with --disable-xnest, but still failed. Thanks, Jeff. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Issue with xf86-input-keyboard: undefined symbol on starting xserver
I am building the XServer following the steps here: http://www.x.org/wiki/CompileXserverManually After getting all the components built successfully (xserver, video driver, mouse driver and keyboard driver), I run the XServer (./Xorg :0). All I get is a blank screen and when I check the Xorg.0.log, I see this error - dlopen /kbd_drv.so: undefined symbol: XkbdfltRepeatInterval and the module does not load. From the logs, it looks like the "mouse" and "intel" (video) modules load correctly. Any idea why it cannot resolve that symbol? -Bipin ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xfree86: Disable all hotplugging features without CONFIG_HAL
On Wed, Jan 28, 2009 at 5:19 PM, Peter Hutterer
wrote:
> On Wed, Jan 28, 2009 at 03:16:45PM -0800, Dan Nicholson wrote:
>> If HAL configuration has not been built into the server, force
>> AutoAddDevices, AutoEnableDevices and AllowEmptyInput to FALSE. The only
>> way to use input devices in this configuration is through xorg.conf.
>>
>> Signed-off-by: Dan Nicholson
>> ---
>> There are still people out there not riding the HAL wave, and this allows
>> them to carry on without applying special server flags.
>>
>> Technically, I think this should also consider CONFIG_DBUS_API, but
>> nothing else in the code does.
>
>
> Why do we need that on top of commit ace38fafb062372dcd3d56378b5b8f86525c6241?
>
> xfree86: without CONFIG_HAL, Auto{Add|Enable}Devices and AEI is false.
Oh, I missed that. That should probably work. I was actually helping
someone with a 1.5.3 server, so I don't think that's in there.
Users can still shoot themselves in the foot by setting the server
flags to true, but with the man patch, they'd at least be informed.
I'll respin with just the man page hunk.
--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xfree86: Disable all hotplugging features without CONFIG_HAL
On Wed, Jan 28, 2009 at 03:16:45PM -0800, Dan Nicholson wrote:
> If HAL configuration has not been built into the server, force
> AutoAddDevices, AutoEnableDevices and AllowEmptyInput to FALSE. The only
> way to use input devices in this configuration is through xorg.conf.
>
> Signed-off-by: Dan Nicholson
> ---
> There are still people out there not riding the HAL wave, and this allows
> them to carry on without applying special server flags.
>
> Technically, I think this should also consider CONFIG_DBUS_API, but
> nothing else in the code does.
Why do we need that on top of commit ace38fafb062372dcd3d56378b5b8f86525c6241?
xfree86: without CONFIG_HAL, Auto{Add|Enable}Devices and AEI is false.
The man page patch looks good though.
Cheers,
Peter
>
> hw/xfree86/common/xf86Config.c | 14 ++
> hw/xfree86/doc/man/xorg.conf.man.pre | 11 ++-
> 2 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
> index 8df9780..20fa631 100644
> --- a/hw/xfree86/common/xf86Config.c
> +++ b/hw/xfree86/common/xf86Config.c
> @@ -833,6 +833,7 @@ configServerFlags(XF86ConfFlagsPtr flagsconf,
> XF86OptionPtr layoutopts)
> xf86Msg(X_CONFIG, "Ignoring ABI Version\n");
> }
>
> +#ifdef CONFIG_HAL
> if (xf86IsOptionSet(FlagOptions, FLAG_AUTO_ADD_DEVICES)) {
> xf86GetOptValBool(FlagOptions, FLAG_AUTO_ADD_DEVICES,
>&xf86Info.autoAddDevices);
> @@ -841,9 +842,14 @@ configServerFlags(XF86ConfFlagsPtr flagsconf,
> XF86OptionPtr layoutopts)
> else {
> from = X_DEFAULT;
> }
> +#else
> +xf86Info.autoAddDevices = FALSE;
> +from = X_DEFAULT;
> +#endif
> xf86Msg(from, "%sutomatically adding devices\n",
> xf86Info.autoAddDevices ? "A" : "Not a");
>
> +#ifdef CONFIG_HAL
> if (xf86IsOptionSet(FlagOptions, FLAG_AUTO_ENABLE_DEVICES)) {
> xf86GetOptValBool(FlagOptions, FLAG_AUTO_ENABLE_DEVICES,
>&xf86Info.autoEnableDevices);
> @@ -852,6 +858,10 @@ configServerFlags(XF86ConfFlagsPtr flagsconf,
> XF86OptionPtr layoutopts)
> else {
> from = X_DEFAULT;
> }
> +#else
> +xf86Info.autoEnableDevices = FALSE;
> +from = X_DEFAULT;
> +#endif
> xf86Msg(from, "%sutomatically enabling devices\n",
> xf86Info.autoEnableDevices ? "A" : "Not a");
>
> @@ -952,9 +962,13 @@ configServerFlags(XF86ConfFlagsPtr flagsconf,
> XF86OptionPtr layoutopts)
> }
> #endif
>
> +#ifdef CONFIG_HAL
> /* AllowEmptyInput is automatically true if we're hotplugging */
> xf86Info.allowEmptyInput = (xf86Info.autoAddDevices &&
> xf86Info.autoEnableDevices);
> xf86GetOptValBool(FlagOptions, FLAG_ALLOW_EMPTY_INPUT,
> &xf86Info.allowEmptyInput);
> +#else
> +xf86Info.allowEmptyInput = FALSE;
> +#endif
>
> /* AEI on? Then we're not using kbd, so use the evdev rules set. */
> #ifdef XKB
> diff --git a/hw/xfree86/doc/man/xorg.conf.man.pre
> b/hw/xfree86/doc/man/xorg.conf.man.pre
> index f5c49e1..987a290 100644
> --- a/hw/xfree86/doc/man/xorg.conf.man.pre
> +++ b/hw/xfree86/doc/man/xorg.conf.man.pre
> @@ -640,19 +640,20 @@ the X server to load. Disabled by default.
> .TP 7
> .BI "Option \*qAllowEmptyInput\*q \*q" boolean \*q
> If enabled, don't add the standard keyboard and mouse drivers, if there are
> no
> -input devices in the config file. Enabled by default if AutoAddDevices and
> -AutoEnableDevices is enabled, otherwise disabled.
> -If AllowEmptyInput is on, devices using the kbd, mouse or vmmouse driver are
> ignored.
> +input devices in the config file. Enabled by default if Xorg has HAL support
> +and AutoAddDevices and AutoEnableDevices are enabled, otherwise disabled.
> +If AllowEmptyInput is on, devices using the kbd, mouse or vmmouse driver are
> +ignored.
> .TP 7
> .BI "Option \*qAutoAddDevices\*q \*q" boolean \*q
> If this option is disabled, then no devices will be added from HAL events.
> -Enabled by default.
> +Enabled by default if Xorg has HAL support.
> .TP 7
> .BI "Option \*qAutoEnableDevices\*q \*q" boolean \*q
> If this option is disabled, then the devices will be added (and the
> DevicePresenceNotify event sent), but not enabled, thus leaving policy up
> to the client.
> -Enabled by default.
> +Enabled by default if Xorg has HAL support.
> .TP 7
> .BI "Option \*qLog\*q \*q" string \*q
> This option controls whether the log is flushed and/or synced to disk after
> --
> 1.5.6.6
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] xfree86: Disable all hotplugging features without CONFIG_HAL
If HAL configuration has not been built into the server, force
AutoAddDevices, AutoEnableDevices and AllowEmptyInput to FALSE. The only
way to use input devices in this configuration is through xorg.conf.
Signed-off-by: Dan Nicholson
---
There are still people out there not riding the HAL wave, and this allows
them to carry on without applying special server flags.
Technically, I think this should also consider CONFIG_DBUS_API, but
nothing else in the code does.
hw/xfree86/common/xf86Config.c | 14 ++
hw/xfree86/doc/man/xorg.conf.man.pre | 11 ++-
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 8df9780..20fa631 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -833,6 +833,7 @@ configServerFlags(XF86ConfFlagsPtr flagsconf, XF86OptionPtr
layoutopts)
xf86Msg(X_CONFIG, "Ignoring ABI Version\n");
}
+#ifdef CONFIG_HAL
if (xf86IsOptionSet(FlagOptions, FLAG_AUTO_ADD_DEVICES)) {
xf86GetOptValBool(FlagOptions, FLAG_AUTO_ADD_DEVICES,
&xf86Info.autoAddDevices);
@@ -841,9 +842,14 @@ configServerFlags(XF86ConfFlagsPtr flagsconf,
XF86OptionPtr layoutopts)
else {
from = X_DEFAULT;
}
+#else
+xf86Info.autoAddDevices = FALSE;
+from = X_DEFAULT;
+#endif
xf86Msg(from, "%sutomatically adding devices\n",
xf86Info.autoAddDevices ? "A" : "Not a");
+#ifdef CONFIG_HAL
if (xf86IsOptionSet(FlagOptions, FLAG_AUTO_ENABLE_DEVICES)) {
xf86GetOptValBool(FlagOptions, FLAG_AUTO_ENABLE_DEVICES,
&xf86Info.autoEnableDevices);
@@ -852,6 +858,10 @@ configServerFlags(XF86ConfFlagsPtr flagsconf,
XF86OptionPtr layoutopts)
else {
from = X_DEFAULT;
}
+#else
+xf86Info.autoEnableDevices = FALSE;
+from = X_DEFAULT;
+#endif
xf86Msg(from, "%sutomatically enabling devices\n",
xf86Info.autoEnableDevices ? "A" : "Not a");
@@ -952,9 +962,13 @@ configServerFlags(XF86ConfFlagsPtr flagsconf,
XF86OptionPtr layoutopts)
}
#endif
+#ifdef CONFIG_HAL
/* AllowEmptyInput is automatically true if we're hotplugging */
xf86Info.allowEmptyInput = (xf86Info.autoAddDevices &&
xf86Info.autoEnableDevices);
xf86GetOptValBool(FlagOptions, FLAG_ALLOW_EMPTY_INPUT,
&xf86Info.allowEmptyInput);
+#else
+xf86Info.allowEmptyInput = FALSE;
+#endif
/* AEI on? Then we're not using kbd, so use the evdev rules set. */
#ifdef XKB
diff --git a/hw/xfree86/doc/man/xorg.conf.man.pre
b/hw/xfree86/doc/man/xorg.conf.man.pre
index f5c49e1..987a290 100644
--- a/hw/xfree86/doc/man/xorg.conf.man.pre
+++ b/hw/xfree86/doc/man/xorg.conf.man.pre
@@ -640,19 +640,20 @@ the X server to load. Disabled by default.
.TP 7
.BI "Option \*qAllowEmptyInput\*q \*q" boolean \*q
If enabled, don't add the standard keyboard and mouse drivers, if there are no
-input devices in the config file. Enabled by default if AutoAddDevices and
-AutoEnableDevices is enabled, otherwise disabled.
-If AllowEmptyInput is on, devices using the kbd, mouse or vmmouse driver are
ignored.
+input devices in the config file. Enabled by default if Xorg has HAL support
+and AutoAddDevices and AutoEnableDevices are enabled, otherwise disabled.
+If AllowEmptyInput is on, devices using the kbd, mouse or vmmouse driver are
+ignored.
.TP 7
.BI "Option \*qAutoAddDevices\*q \*q" boolean \*q
If this option is disabled, then no devices will be added from HAL events.
-Enabled by default.
+Enabled by default if Xorg has HAL support.
.TP 7
.BI "Option \*qAutoEnableDevices\*q \*q" boolean \*q
If this option is disabled, then the devices will be added (and the
DevicePresenceNotify event sent), but not enabled, thus leaving policy up
to the client.
-Enabled by default.
+Enabled by default if Xorg has HAL support.
.TP 7
.BI "Option \*qLog\*q \*q" string \*q
This option controls whether the log is flushed and/or synced to disk after
--
1.5.6.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: general question: xorg & Nvdriver
Okay - thank you both. I didn't know that this is an artifact - ergo useless. But ... I'm again, at the beginning ... Backtrace: 0: /home/fl0/mpxcompiz/bin/Xorg(xorg_backtrace+0x3b) [0x80e829b] 1: /home/fl0/mpxcompiz/bin/Xorg(xf86SigHandler+0x51) [0x809ccb1] 2: [0xb80ea400] 3: /home/fl0/mpxcompiz/bin/Xorg(xf86SetDesiredModes+0x27b) [0x80ab18b] 4: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7bd612c] 5: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7bd6562] 6: /home/fl0/mpxcompiz/bin/Xorg(AddScreen+0x19d) [0x80684ad] 7: /home/fl0/mpxcompiz/bin/Xorg(InitOutput+0x23a) [0x808b12a] 8: /home/fl0/mpxcompiz/bin/Xorg [0x8068ba1] 9: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7c8b685] 10: /home/fl0/mpxcompiz/bin/Xorg [0x8068231] Fatal server error: Caught signal 11. Server aborting THIS drives me crazy. fl0 Stephane Marchesin wrote: On Wed, Jan 28, 2009 at 23:43, Maarten Maathuis wrote: On Wed, Jan 28, 2009 at 11:21 PM, Stephane Marchesin wrote: 2009/1/28 Florian Lier : Okay, new problem: I tried to "insmod" the nvdriver...this is the result: insmod: error inserting 'drm/linux-core/nv.ko': -1 Unknown symbol in module Any suggestions? There is no nv.ko module. There is a nouveau.ko module, an nvidia.ko proprietary module, but no nv module. There is an nv.ko, but it is a useless placeholder that exists for unknown reasons. It existed a couple of months before nouveau and was intended to help extend nv to do exa. However, this never happened. So technically today that module is useless. Maybe we should remove it from git someday. Stephane ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg begin:vcard fn:Florian Lier n:Lier;Florian org:;AG AI | so far adr:;;Germany email;internet:f...@icram.de title:B. Sc. Informatics tel;work:University | AG Angewandte Informatik tel;home:/home/usr x-mozilla-html:FALSE url:www.icram.de version:2.1 end:vcard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: general question: xorg & Nvdriver
On Wed, Jan 28, 2009 at 23:43, Maarten Maathuis wrote: > On Wed, Jan 28, 2009 at 11:21 PM, Stephane Marchesin > wrote: >> 2009/1/28 Florian Lier : >>> Okay, new problem: >>> >>> I tried to "insmod" the nvdriver...this is the result: >>> >>> insmod: error inserting 'drm/linux-core/nv.ko': -1 Unknown symbol in module >>> >>> Any suggestions? >> >> There is no nv.ko module. There is a nouveau.ko module, an nvidia.ko >> proprietary module, but no nv module. > > There is an nv.ko, but it is a useless placeholder that exists for > unknown reasons. > It existed a couple of months before nouveau and was intended to help extend nv to do exa. However, this never happened. So technically today that module is useless. Maybe we should remove it from git someday. Stephane ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: general question: xorg & Nvdriver
On Wed, Jan 28, 2009 at 11:21 PM, Stephane Marchesin wrote: > 2009/1/28 Florian Lier : >> Okay, new problem: >> >> I tried to "insmod" the nvdriver...this is the result: >> >> insmod: error inserting 'drm/linux-core/nv.ko': -1 Unknown symbol in module >> >> Any suggestions? > > There is no nv.ko module. There is a nouveau.ko module, an nvidia.ko > proprietary module, but no nv module. There is an nv.ko, but it is a useless placeholder that exists for unknown reasons. > > Stephane > ___ > 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: XkbGetCoreMap
Pierre Willenbrock wrote: > Hi, Hi, > i think there are a few things wrong in XkbGetCoreMap. It looks like > there is some code that was duplicated(judging from a hanging xserver > and the predecessor function), an off-by-one in the size calculation and > some uninitilized members of the KeySymsRec. I am not sure about the > latter, but if these members should not be set, they probably should be > removed from KeySymsRec. I git bisect'ed to that code last night, as one possible cause of http://bugs.freedesktop.org/show_bug.cgi?id=19776 but I did not debug it, just looked over the changes; I will try your patch, it makes sense, and hopefully will correct my problem (not having a functional text editor is hard...) > Patch attached. > > Regards, > Pierre Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: general question: xorg & Nvdriver
2009/1/28 Florian Lier : > Okay, new problem: > > I tried to "insmod" the nvdriver...this is the result: > > insmod: error inserting 'drm/linux-core/nv.ko': -1 Unknown symbol in module > > Any suggestions? There is no nv.ko module. There is a nouveau.ko module, an nvidia.ko proprietary module, but no nv module. Stephane ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
XkbGetCoreMap
Hi,
i think there are a few things wrong in XkbGetCoreMap. It looks like
there is some code that was duplicated(judging from a hanging xserver
and the predecessor function), an off-by-one in the size calculation and
some uninitilized members of the KeySymsRec. I am not sure about the
latter, but if these members should not be set, they probably should be
removed from KeySymsRec.
Patch attached.
Regards,
Pierre
commit df98656dadd0766913ce7fa51ca436796b112bad
Author: Pierre Willenbrock
Date: Wed Jan 28 22:18:50 2009 +0100
Fix duplicate code, off-by one in space calculation, not initialized members
diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index c24b303..3a8d129 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -425,8 +425,10 @@ int maxNumberOfGroups;
maxSymsPerKey = maxNumberOfGroups * maxGroup1Width;
syms->mapWidth = maxSymsPerKey;
+syms->minKeyCode = xkb->min_key_code;
+syms->maxKeyCode = xkb->max_key_code;
-tmp = syms->mapWidth * (xkb->max_key_code - xkb->min_key_code);
+tmp = syms->mapWidth * (xkb->max_key_code - xkb->min_key_code + 1);
syms->map = xcalloc(tmp, sizeof(*syms->map));
if (!syms->map) {
xfree(syms);
@@ -458,7 +460,7 @@ int maxNumberOfGroups;
*/
if (nGroups == 1)
{
- int idx;
+ int idx, j;
groupWidth = XkbKeyGroupWidth(xkb, key, XkbGroup1Index);
@@ -473,39 +475,16 @@ int maxNumberOfGroups;
while (groupWidth > 2 && idx < syms->mapWidth &&
idx < groupWidth * 2)
{
- int idx, j;
-
- groupWidth = XkbKeyGroupWidth(xkb, key, XkbGroup1Index);
-
- /* AB..CDE... -> ABABCDE... */
- if (groupWidth > 0 && maxSymsPerKey >= 3)
- pCore[2] = pCore[0];
- if (groupWidth > 1 && maxSymsPerKey >= 4)
- pCore[3] = pCore[1];
-
- /* ABABCDE... -> ABABCDECDE */
- idx = 2 + groupWidth;
- while (groupWidth > 2 &&
- idx < maxSymsPerKey &&
- idx < groupWidth * 2)
- {
- pCore[idx] = pCore[idx - groupWidth + 2];
- idx++;
- }
- idx = 2 * groupWidth;
- if (idx < 4)
- idx = 4;
- /* 3 or more groups: ABABCDECDEABCDEABCDE */
-for (j = 3; j <= maxNumberOfGroups; j++)
-for (n = 0; n < groupWidth && idx < maxSymsPerKey; n++)
-pCore[idx++] = pXKB[n];
+ pCore[idx] = pCore[idx - groupWidth + 2];
+ idx++;
}
idx = 2 * groupWidth;
if (idx < 4)
idx = 4;
/* 3 or more groups: ABABCDECDEABCDEABCDE */
- for (n = 0; n < groupWidth && idx < syms->mapWidth; n++)
- pCore[idx++] = pXKB[n];
+ for (j = 3; j <= maxNumberOfGroups; j++)
+ for (n = 0; n < groupWidth && idx < maxSymsPerKey; n++)
+ pCore[idx++] = pXKB[n];
}
pXKB+= XkbKeyGroupsWidth(xkb,key);
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: general question: xorg & Nvdriver
Okay, new problem: I tried to "insmod" the nvdriver...this is the result: / insmod: error inserting 'drm/linux-core/nv.ko': -1 Unknown symbol in module /Any suggestions? Cheers, florian/ / Beso wrote: 2009/1/28 Florian Lier : Hey all, I'm trying to get the current (X.Org X Server 1.6.99.1) "X" running on several "test-systems" for like 2 or 3 months now. (for mpx purposes) I tested several systems with ATI, INTEL and NVIDIA gcards... The most "difficult" system seems to be the one with NVIDIA cards. As far as I can interpret the backtrace there is always a problem with the nv driver. Backtrace: 0: /home/fl0/mpxcompiz/bin/Xorg(xorg_backtrace+0x3b) [0x80e829b] 1: /home/fl0/mpxcompiz/bin/Xorg(xf86SigHandler+0x51) [0x809ccb1] 2: [0xb7f78400] 3: /home/fl0/mpxcompiz/bin/Xorg(xf86SetDesiredModes+0x27b) [0x80ab18b] 4: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a6412c] 5: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a64562] 6: /home/fl0/mpxcompiz/bin/Xorg(AddScreen+0x19d) [0x80684ad] 7: /home/fl0/mpxcompiz/bin/Xorg(InitOutput+0x23a) [0x808b12a] 8: /home/fl0/mpxcompiz/bin/Xorg [0x8068ba1] 9: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7b19685] 10: /home/fl0/mpxcompiz/bin/Xorg [0x8068231] try manually modprobing drm and the nv driver before starting xorg. i've been having a very similar issue with radeon driver for a long time and the only workaround is modprobing the modules before startup. i've learned about this workaround from another user who had the same issues with the intel driver. begin:vcard fn:Florian Lier n:Lier;Florian org:;AG AI | so far adr:;;Germany email;internet:f...@icram.de title:B. Sc. Informatics tel;work:University | AG Angewandte Informatik tel;home:/home/usr x-mozilla-html:FALSE url:www.icram.de version:2.1 end:vcard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: bug in xfont xlfd rounding code
On Thu, Jan 29, 2009 at 2:17 AM, Michel Dänzer wrote: > On Wed, 2009-01-28 at 21:48 +1000, Dave Airlie wrote: >> >> Maybe someone understand wtf the code in >> libXfont/util/fontxlfd.c:xlfd_round_double >> is all about, but the results were different on different endian >> machines due to the code >> being hardcoded for little endian. >> >> I reimplemented it for other endian, however I'm unsure about the >> endian detect code on other OSes, >> it just uses the autoconf macros. > > Not sure it's that simple - IIRC there are differences in the order of > the two 32 bit halves of a double even within big/little endian > architectures. > Well thats why it tests the bytes 6/7 first to make sure the ordering is correct before using the broken (for whatever reason) printf codepath. It works for me on powerpc which is really the only one I cared about at the moment. Dave. > > -- > 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: general question: xorg & Nvdriver
On Wed, Jan 28, 2009 at 11:12:23AM -0800, Florian Lier wrote: > Hey all, > > I'm trying to get the current (X.Org X Server 1.6.99.1) "X" running on > several "test-systems" for like 2 or 3 months now. (for mpx purposes) > I tested several systems with ATI, INTEL and NVIDIA gcards... > The most "difficult" system seems to be the one with NVIDIA cards. > As far as I can interpret the backtrace there is always a problem with the nv > driver. > > Backtrace: > 0: /home/fl0/mpxcompiz/bin/Xorg(xorg_backtrace+0x3b) [0x80e829b] > 1: /home/fl0/mpxcompiz/bin/Xorg(xf86SigHandler+0x51) [0x809ccb1] > 2: [0xb7f78400] > 3: /home/fl0/mpxcompiz/bin/Xorg(xf86SetDesiredModes+0x27b) [0x80ab18b] > 4: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a6412c] > 5: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a64562] > 6: /home/fl0/mpxcompiz/bin/Xorg(AddScreen+0x19d) [0x80684ad] > 7: /home/fl0/mpxcompiz/bin/Xorg(InitOutput+0x23a) [0x808b12a] > 8: /home/fl0/mpxcompiz/bin/Xorg [0x8068ba1] > 9: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7b19685] > 10: /home/fl0/mpxcompiz/bin/Xorg [0x8068231] The nv driver calls back into the X server to set the first mode by calling xf86SetDesiredModes, which is crashing somewhere. This sounds like a regression in the X server. I'd recommend getting a debug X server, catching the crash in GDB, and then getting a backtrace. It's possible that the nv driver is doing something funky to the modepool that confuses xf86SetDesiredModes, but your modes look pretty normal. > Does anyone of you know a revision which doesn't stuck on startup including > the nv-driver? > Pls, correct me if I'm wrong with the nv driver thang. > > I also check out the xorg tinderbox from time to time ... seems that the last > time the master branch compiled > successfully was 2009-01-20. > > cheers, fl0 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: general question: xorg & Nvdriver
Hey Beso, thank you! I'll give it a try! I wrote a start script for X maybe I'll add a modprobe line... #!/bin/bash ## MPX RUN() Script v1.0 by ## LIBEX="/home/fl0/mpxcompiz/lib" CONFPATH="/home/fl0/mpxcompiz/xorg.conf" MPXPATH="/home/fl0/mpxcompiz/bin/Xorg" DRMPATH="/home/fl0/mpxcompiz/drm/linux-core/drm.ko" echo "+++ MPX Startscript V 0.1 +++" /etc/init.d/gdm stop echo "removing standard DRM Module" sleep 3 rmmod drm echo DRM_PATH is: $DRMPATH sleep 4 insmod $DRMPATH echo LD_LIBRARY_PATH is: $LIBEX export LD_LIBRARY_PATH=$LIBEX echo Starting Server on Display 2 sleep 4 startx -- $MPXPATH :2 -config $CONFPATH -verbose exit #proper way to leave a script Beso wrote: 2009/1/28 Florian Lier : Hey all, I'm trying to get the current (X.Org X Server 1.6.99.1) "X" running on several "test-systems" for like 2 or 3 months now. (for mpx purposes) I tested several systems with ATI, INTEL and NVIDIA gcards... The most "difficult" system seems to be the one with NVIDIA cards. As far as I can interpret the backtrace there is always a problem with the nv driver. Backtrace: 0: /home/fl0/mpxcompiz/bin/Xorg(xorg_backtrace+0x3b) [0x80e829b] 1: /home/fl0/mpxcompiz/bin/Xorg(xf86SigHandler+0x51) [0x809ccb1] 2: [0xb7f78400] 3: /home/fl0/mpxcompiz/bin/Xorg(xf86SetDesiredModes+0x27b) [0x80ab18b] 4: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a6412c] 5: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a64562] 6: /home/fl0/mpxcompiz/bin/Xorg(AddScreen+0x19d) [0x80684ad] 7: /home/fl0/mpxcompiz/bin/Xorg(InitOutput+0x23a) [0x808b12a] 8: /home/fl0/mpxcompiz/bin/Xorg [0x8068ba1] 9: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7b19685] 10: /home/fl0/mpxcompiz/bin/Xorg [0x8068231] try manually modprobing drm and the nv driver before starting xorg. i've been having a very similar issue with radeon driver for a long time and the only workaround is modprobing the modules before startup. i've learned about this workaround from another user who had the same issues with the intel driver. begin:vcard fn:Florian Lier n:Lier;Florian org:;AG AI | so far adr:;;Germany email;internet:f...@icram.de title:B. Sc. Informatics tel;work:University | AG Angewandte Informatik tel;home:/home/usr x-mozilla-html:FALSE url:www.icram.de version:2.1 end:vcard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: general question: xorg & Nvdriver
2009/1/28 Florian Lier : > Hey all, > > I'm trying to get the current (X.Org X Server 1.6.99.1) "X" running on > several "test-systems" for like 2 or 3 months now. (for mpx purposes) > I tested several systems with ATI, INTEL and NVIDIA gcards... > The most "difficult" system seems to be the one with NVIDIA cards. > As far as I can interpret the backtrace there is always a problem with the > nv driver. > > Backtrace: > 0: /home/fl0/mpxcompiz/bin/Xorg(xorg_backtrace+0x3b) [0x80e829b] > 1: /home/fl0/mpxcompiz/bin/Xorg(xf86SigHandler+0x51) [0x809ccb1] > 2: [0xb7f78400] > 3: /home/fl0/mpxcompiz/bin/Xorg(xf86SetDesiredModes+0x27b) [0x80ab18b] > 4: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a6412c] > 5: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a64562] > 6: /home/fl0/mpxcompiz/bin/Xorg(AddScreen+0x19d) [0x80684ad] > 7: /home/fl0/mpxcompiz/bin/Xorg(InitOutput+0x23a) [0x808b12a] > 8: /home/fl0/mpxcompiz/bin/Xorg [0x8068ba1] > 9: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7b19685] > 10: /home/fl0/mpxcompiz/bin/Xorg [0x8068231] > try manually modprobing drm and the nv driver before starting xorg. i've been having a very similar issue with radeon driver for a long time and the only workaround is modprobing the modules before startup. i've learned about this workaround from another user who had the same issues with the intel driver. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
general question: xorg & Nvdriver
Hey all, I'm trying to get the current (X.Org X Server 1.6.99.1) "X" running on several "test-systems" for like 2 or 3 months now. (for mpx purposes) I tested several systems with ATI, INTEL and NVIDIA gcards... The most "difficult" system seems to be the one with NVIDIA cards. As far as I can interpret the backtrace there is *always* a problem with the nv driver. Backtrace: 0: /home/fl0/mpxcompiz/bin/Xorg(xorg_backtrace+0x3b) [0x80e829b] 1: /home/fl0/mpxcompiz/bin/Xorg(xf86SigHandler+0x51) [0x809ccb1] 2: [0xb7f78400] 3: /home/fl0/mpxcompiz/bin/Xorg(xf86SetDesiredModes+0x27b) [0x80ab18b] 4: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a6412c] 5: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a64562] 6: /home/fl0/mpxcompiz/bin/Xorg(AddScreen+0x19d) [0x80684ad] 7: /home/fl0/mpxcompiz/bin/Xorg(InitOutput+0x23a) [0x808b12a] 8: /home/fl0/mpxcompiz/bin/Xorg [0x8068ba1] 9: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7b19685] 10: /home/fl0/mpxcompiz/bin/Xorg [0x8068231] Does anyone of you know a revision which doesn't stuck on startup including the nv-driver? Pls, correct me if I'm wrong with the nv driver thang. I also check out the xorg tinderbox from time to time ... seems that the last time the master branch compiled successfully was 2009-01-20. cheers, fl0 P.S: Here's the complete Xorg.log: This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.6.99.1 Release Date: (unreleased) X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.27-11-generic i686 Current Operating System: Linux m0thership 2.6.27-11-generic #1 SMP Thu Jan 22 17:22:40 UTC 2009 i686 Build Date: 28 January 2009 11:44:14AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/home/fl0/mpxcompiz/var/log/Xorg.2.log", Time: Wed Jan 28 12:14:21 2009 (++) Using config file: "/home/fl0/mpxcompiz/xorg.conf" (==) No Layout section. Using the first Screen section. (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Configured Monitor" (**) | |-->Device "Configured Video Device" (==) Not automatically adding devices (==) Not automatically enabling devices (WW) The directory "/home/fl0/mpxcompiz/lib/X11/fonts/misc/" does not exist. Entry deleted from font path. (WW) The directory "/home/fl0/mpxcompiz/lib/X11/fonts/TTF/" does not exist. Entry deleted from font path. (WW) The directory "/home/fl0/mpxcompiz/lib/X11/fonts/OTF" does not exist. Entry deleted from font path. (WW) The directory "/home/fl0/mpxcompiz/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) The directory "/home/fl0/mpxcompiz/lib/X11/fonts/100dpi/" does not exist. Entry deleted from font path. (WW) The directory "/home/fl0/mpxcompiz/lib/X11/fonts/75dpi/" does not exist. Entry deleted from font path. (==) FontPath set to: built-ins (==) ModulePath set to "/home/fl0/mpxcompiz/lib/xorg/modules" (==) |-->Input Device "" (==) |-->Input Device "" (==) No Layout section. Using the default mouse configuration. (==) No Layout section. Using the default keyboard configuration. (II) Loader magic: 0xf75a0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 5.0 X.Org Server Extension : 2.0 (II) Loader running on linux (--) using VT number 7 (--) PCI:*(0...@1:0:0) unknown vendor (0x10de) unknown chipset (0x0193) rev 162, Mem @ 0xfd00/16777216, 0xd000/268435456, 0xfa00/33554432, I/O @ 0xbc00/128, BIOS @ 0x/131072 (II) Open ACPI successful (/var/run/acpid.socket) (II) System resource ranges: [0] -100x - 0x (0x1) MX[B] [1] -100x000f - 0x000f (0x1) MX[B] [2] -100x000c - 0x000e (0x3) MX[B] [3] -100x - 0x0009 (0xa) MX[B] [4] -100x - 0x (0x1) IX[B] [5] -100x - 0x (0x1) IX[B] (II) "extmod" will be loaded by default. (II) "dbe" will be loaded by default. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded by default. (II) "dri2" will be loaded by default. (II) LoadModule: "glx" (II) Loading /home/fl0/mpxcompiz/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.99.1, module version = 1.0.0 ABI
Re: libXrender - documentation?
Charles Lindsey wrote: > Now I am using Solaris-10 as my operating system, and libXrender and > libxft come bundled with it, and its documentation proudly proclaims > >"This feature [the XRender Extension] is included in the Solaris 10 >3/05 release" (and it was actually in Solaris-9 before that). > > So I poked around using truss and the Debug facility in libxft, and > discovered that the Opera/QT/Solaris combination always took the xftcore > route. Finally, in desperation, I tried 'xdpyinfo -ext RENDER' and it told > me: > > RENDER extension not supported by server > > Aaaarhh! Render support on Solaris 10 depends on which X server & drivers you use. On x86/x64 hardware, use the Xorg server (which is default in Solaris 10 and later on that hardware) and Render should be supported on almost all hardware/drivers. On SPARC hardware, the drivers for the Xsun server only support render on some graphics cards, and some require patches from SunSolve and/or adding +xrender to the Xsun command line options to enable it. -- -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: keysymdef.h has wrong implies symbol?
Daniel Stone wrote on 2009-01-27 01:16 UTC: > On Mon, Jan 26, 2009 at 01:14:07PM +, Markus Kuhn wrote: > > P.S.: The real problem may be that X.Org seems not to maintain a well > > publicised canonical long-term PDF URL for the current "X Window System ^^^ > > Protocol" specification and similar documents, therefore far too few > > people read the spec itself and instead keep refering to various *.h > > include files. > > http://www.x.org/docs/XProtocol/proto.pdf I'm afraid, that is not the "current" version. The above URL gives me the outdated Release 6.7 version of the spec, whereas the keysym<->Unicode mappings in Appendix A were added with the Release 6.9/7.0 version. So there is something broken in the way http://www.x.org/docs/ is updated. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libXrender - documentation?
In <194f62550901261140q12d1ed46k9075ebcc83dea...@mail.gmail.com> Clemens Eisserer writes: >> I can't see any such calls of XRender* functions in the bits of xft that I >> have been looking at (notably in xftcore.c). >Because xft deals with Glyphs, and for performance/bandwith resons >glyphs are handled in a special manner. >That was what I ment with "(using the XRender*Glyphs functions)". >xftglyphs: XRenderAddGlyphs >xftrender: XRenderCompositeText... OK, since you wrote that I have been poking around in the xft source, and the situation seems to be as follows: Libxft contains two modules (xftcore and xftrender). One does antialiassing client-side (with much consumption of cpu resources, some of it unnecessarily) and the other does it client side by calling XRenderCompositeText16 and friends (and I don't know what goes on behind those calls, because of lack of documentation thereof :-) ). To decide which to use, libxft first calls XRenderQueryExtension to see it the server is willing, and then calls XRenderFindVisualFormat to see whether the visual is suitable, and then calls XRenderFindFormat to see whether the particular font is capable. If any of those fails, it falls back to xftcore. Now I am using Solaris-10 as my operating system, and libXrender and libxft come bundled with it, and its documentation proudly proclaims "This feature [the XRender Extension] is included in the Solaris 10 3/05 release" (and it was actually in Solaris-9 before that). So I poked around using truss and the Debug facility in libxft, and discovered that the Opera/QT/Solaris combination always took the xftcore route. Finally, in desperation, I tried 'xdpyinfo -ext RENDER' and it told me: RENDER extension not supported by server Aaaarhh! So it is evidently a SUN problem, and I shall pursue it in that quarter. In the meantime, I apologise for impugning the ability of libxft to do antialiassing properly when presented with the proper environment. >>>However as far as I know xft already has a XRender aware backend >>>(using the XRender*Glyphs functions), as well as legacy support for >>>pre-xrender servers. Yes, I can now see that is the case. >> But who is actually responsible for the development/maintenance of xft? >> For sure they do not seem to hang around on this list, though I gather >> they are within the overall Xorg structure somewhere. >XFT is more or less a sample implementation, and as far as I know its >not used a lot. Well, apart from QT (possibly older versions), it is certainly used by Adobe in the freely available 'acroread', and I think that would count as "a lot". -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libXrender - documentation?
In <871vupgnte@opera.com> Eirik Byrkjeflot Anonsen writes: >Clemens Eisserer writes: >[...] >>> For sure the Opera/QT combination is not doing anything like that - all >>> the calls that actually pass glyphs to/from the server use good ol' Xlib. >>> Though there is evidence that xft does use Xrender elsewhere in its >>> workings. >> I don't know about opera, but im am pretty (99,5%) sure QT uses Render >> - now if Opera uses QT's graphic context for drawing it will >> implicitly use it. >The text handling in Qt 2 was abysmal (in particular the font >switching), so we (opera) implemented our own. I don't think we've >changed it much since then. I believe our implementation uses xft and >"classic x fonts" directly. Well, since my copy of Opera has QT bundled inside it, I cannot tell which is actually making the xft calls. But for sure, every time the cursor blinks in a mail-editing window, Opera/QT (whichever) calls XftDrawString16 on every word in the whole window, just on the offchance that words happens to overlap the cursor area. And if libxft is doing its own antialiassing (see my reply to Clemens regarding Solaris-10), the resultant cpu usage hogs 100% (and more if it could) of the processor. Which is plain silly (and I shall be moaning to you in opera.os.solaris about it once I have established exactly why Sun have messed it up :-( ). -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 1.4 -> 1.5.1 performance regressions
On Wed, 2009-01-28 at 16:20 +0100, Fabio wrote: > > I am getting these results with gtkperf, compared to what I got with > 1.4. Note, however, that not all performance differences could be due > to the X server, since I upgraded all system during that time (the > radeon driver however is almost the same): If the GTK version / theme is different, that could indeed easily make a difference. Without trying the patch, it's hard to say what its impact will be on your numbers. > See also https://bugs.freedesktop.org/show_bug.cgi?id=16647#c24 dixLookupPrivate should now essentially be an array lookup again, so any overhead this still incurs should have been there in 1.4 already, unless EXA calls dixLookupPrivate significantly more often now... I'll look into further reducing this by passing around pointers to the EXA private data directly internally, but I'm not sure how far that will go. And even if this overhead was removed completely, 10% speedup would be barely noticeable in practice if at all. -- 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: Missing freetype module
Rebuild with ./configure --disable-builtin-fonts Jacek Luczak wrote: > Hi All, > > I'm now running xorg-server 1.5.99.901 and it lacks of freetype module: > (II) LoadModule: "freetype" > (WW) Warning, couldn't open module freetype > (II) UnloadModule: "freetype" > (EE) Failed to load module "freetype" (module does not exist, 0) > > I know that Type1 module has been removed and freetype taking it's > responsibilities, so I believe it's still present, or at least should be. > xlsfonts returns only fixed ones: > -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1 > -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1 > -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 > 6x13 > cursor > fixed > > Regards, > -Jacek > > Details: > > FreeType version: 2.3.8 > > Xserver configure: > ./configure --prefix=/usr \ > --sysconfdir=/etc \ > --localstatedir=/var \ > --infodir=/usr/info \ > --mandir=/usr/man \ > --disable-ipv6 \ > --enable-dri \ > --disable-dmx \ > --enable-composite \ > --enable-xcsecurity \ > --enable-xorg \ > --enable-xtrap \ > --enable-glx-tls \ > --enable-xorgcfg \ > --enable-kdrive \ > --enable-install-setuid \ > --enable-config-hal \ > --enable-config-dbus \ > --enable-dri2 \ > --disable-xsdl \ > --disable-kdrive-vesa \ > --disable-xprint \ > --disable-static \ > > --with-default-font-path="/usr/share/fonts/TTF,/usr/share/fonts/OTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/75dpi/:unscaled" > \ > --with-module-dir=/usr/lib/xorg/modules \ > --with-dri-driver-path=/usr/lib/xorg/modules/dri \ > --with-os-name="Slackware 12.1" \ > --with-os-vendor="Beton Project for Slackware Linux Project" \ > --with-xkb-path=/etc/X11/xkb \ > --with-xkb-output=/var/lib/xkb > > > > > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg -- -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: bug in xfont xlfd rounding code
On Wed, 2009-01-28 at 21:48 +1000, Dave Airlie wrote: > > Maybe someone understand wtf the code in > libXfont/util/fontxlfd.c:xlfd_round_double > is all about, but the results were different on different endian > machines due to the code > being hardcoded for little endian. > > I reimplemented it for other endian, however I'm unsure about the > endian detect code on other OSes, > it just uses the autoconf macros. Not sure it's that simple - IIRC there are differences in the order of the two 32 bit halves of a double even within big/little endian architectures. -- 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: 1.4 -> 1.5.1 performance regressions
> On Tue, 2009-01-27 at 12:42 +0100, Fabio wrote: > > > On Tue, 2009-01-27 at 11:55 +0100, Fabio wrote: > > > > > On Thu, 2008-10-09 at 11:02 +0200, Fabio wrote: > > > > > > > > > > > > I noticed some performance regression moving to a newer system with > > > > > > Xserver > > > > > > 1.5.1 from an 1.4 system with both XAA and EXA. > > > > > > > > > > Can you try current Git server-1.5-branch? Adam Jackson just > > > > > backported > > > > > the reduction of dixLookupPrivate() overhead, which is used > > > > > extensively > > > > > by the EXA core at least. If there are still regressions with EXA, I'd > > > > > be interested in sysprof/oprofile data separately for each regressed > > > > > case. > > > > > > > > I noticed that pre-1.6 is faster than 1.5.3, but still slower than 1.4. > > > > > > > > As reported by someone in the bug report, the patch from > > > > https://bugs.freedesktop.org/show_bug.cgi?id=16647#c11 was never > > > > applied. Is it still needed? > > > > > > Have you tried it to see if it helps for the performance regressions you > > > noticed? > > > > No (I am using prebuilt packages), however, according to this comment, it > > fixes the regression: > > https://bugs.freedesktop.org/show_bug.cgi?id=16647#c14 > > ... for the benchmark / workloads discussed in the bug report. Are the > workloads you noticed the performance regression with similar to those? I am getting these results with gtkperf, compared to what I got with 1.4. Note, however, that not all performance differences could be due to the X server, since I upgraded all system during that time (the radeon driver however is almost the same): + -> faster - -> slower = -> about the same 1.4 1.5.99.901 Difference GtkEntry - time: 0,090,09= GtkComboBox - time: 3,835,74- GtkComboBoxEntry - time: 2,964,53- GtkSpinButton- time: 0,510,53= GtkProgressBar - time: 0,270,24= GtkToggleButton - time: 1,340,50+ GtkCheckButton - time: 1,440,28+ GtkRadioButton - time: 1,790,77+ GtkTextView - Add text - time: 11,68 11,96= GtkTextView - Scroll - time: 2,842,22+ GtkDrawingArea - Lines - time: 2,434,90- GtkDrawingArea - Circles - time: 1,863,77- GtkDrawingArea - Text- time: 3,893,42+ GtkDrawingArea - Pixbufs - time: 0,300,36- --- Total- time: 35,22 39,33- See also https://bugs.freedesktop.org/show_bug.cgi?id=16647#c24 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: bug in xfont xlfd rounding code
Dave Airlie writes: > Hi guys, > > Maybe someone understand wtf the code in > libXfont/util/fontxlfd.c:xlfd_round_double > is all about, but the results were different on different endian > machines due to the code > being hardcoded for little endian. Which is to say "x86 layout". > I reimplemented it for other endian, however I'm unsure about the > endian detect code on other OSes, > it just uses the autoconf macros. I'm not convinced that floating point layout is a plain big/little endianness that follows the integer endianness. But it's been some time since I had to worry about that... eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: bug in xfont xlfd rounding code
Dave Airlie schrieb: > Hi guys, > > Maybe someone understand wtf the code in > libXfont/util/fontxlfd.c:xlfd_round_double > is all about, but the results were different on different endian > machines due to the code > being hardcoded for little endian. > > I reimplemented it for other endian, however I'm unsure about the > endian detect code on other OSes, > it just uses the autoconf macros. > hi dave, looks nice. the code does not seem to be used often. can you test what the speed penalty of using the general case is ? re, wh ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keyboard events and console switching
On Jan 23, 09 10:27:12 +1100, Daniel Stone wrote: > On Thu, Jan 22, 2009 at 05:36:52PM +0100, Matthias Hopf wrote: > > On Jan 22, 09 16:55:08 +0100, Helge Bahmann wrote: > > > Things get even more unfriendly if console switching is initiated by chvt > > > from > > > a background service (don't ask). I propose to change the current logic > > > for > > > releasing keys on VT switch -- release them before switching away from > > > the > > > server, instead of after switching back. Would a patch like the attached > > > one > > > be acceptable? > > > > We have several bugs open for openSUSE because of this behavior - so I'm > > all for a change. I don't know the inner workings of this area in X, so > > I can't claim to understand the patch completely, but I will give it a > > try. So if it works, I really suggest taking it. > > It should already work: please file a bug and assign it to me, and I'll > take care of it ASAP. The issue is that we were never able to reproduce these bugs here at SuSE - but for some people they find the same behavior for a long time already. It's also possible that this only surfaces with the openSUSE X.org server - you never know... I'll verify and get back to you. Thanks Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
bug in xfont xlfd rounding code
Hi guys, Maybe someone understand wtf the code in libXfont/util/fontxlfd.c:xlfd_round_double is all about, but the results were different on different endian machines due to the code being hardcoded for little endian. I reimplemented it for other endian, however I'm unsure about the endian detect code on other OSes, it just uses the autoconf macros. Patch attached. Dave. xlfd.patch Description: Binary data ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Missing freetype module
Hi All, I'm now running xorg-server 1.5.99.901 and it lacks of freetype module: (II) LoadModule: "freetype" (WW) Warning, couldn't open module freetype (II) UnloadModule: "freetype" (EE) Failed to load module "freetype" (module does not exist, 0) I know that Type1 module has been removed and freetype taking it's responsibilities, so I believe it's still present, or at least should be. xlsfonts returns only fixed ones: -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1 -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 6x13 cursor fixed Regards, -Jacek Details: FreeType version: 2.3.8 Xserver configure: ./configure --prefix=/usr \ --sysconfdir=/etc \ --localstatedir=/var \ --infodir=/usr/info \ --mandir=/usr/man \ --disable-ipv6 \ --enable-dri \ --disable-dmx \ --enable-composite \ --enable-xcsecurity \ --enable-xorg \ --enable-xtrap \ --enable-glx-tls \ --enable-xorgcfg \ --enable-kdrive \ --enable-install-setuid \ --enable-config-hal \ --enable-config-dbus \ --enable-dri2 \ --disable-xsdl \ --disable-kdrive-vesa \ --disable-xprint \ --disable-static \ --with-default-font-path="/usr/share/fonts/TTF,/usr/share/fonts/OTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/75dpi/:unscaled" \ --with-module-dir=/usr/lib/xorg/modules \ --with-dri-driver-path=/usr/lib/xorg/modules/dri \ --with-os-name="Slackware 12.1" \ --with-os-vendor="Beton Project for Slackware Linux Project" \ --with-xkb-path=/etc/X11/xkb \ --with-xkb-output=/var/lib/xkb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Hardware accelaration of DRAWABLE_WINDOW's in kdrive
Can drawable of type DRAWABLE_WINDOW get hardware accelerated from kaaCopyNtoN function of kdrive ? At the start of kaaCopyNtoN function there is a if check for pSrcDrawable->type == DRAWABLE_PIXMAP, so in case of WINDOW it will fail to enter inside this if condition and hence will not go through the logic that will bring it to offscreen buffer for hardware acceleration. As per my understanding, kdrive allocates both PIXMAP's and WINDOWs in system memory, then depending on there hits, score is increased. When score equals to certain threshold they are move into the Offscreen buffer. This holds true for PIXMAP's but I couldn't understood which part of kdrive code moves WINDOW's allocated in system memory to offscreen memory. Thanks, Yogish Kulkarni ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libXrender - documentation?
"Nicolas Mailhot" writes: > Le Mar 27 janvier 2009 09:23, Eirik Byrkjeflot Anonsen a écrit : > >> The text handling in Qt 2 was abysmal (in particular the font >> switching), so we (opera) implemented our own. I don't think we've >> changed it much since then. I believe our implementation uses xft and >> "classic x fonts" directly. > > QT and pango have been merging behind the scene (harfbuzz). It would > be nice if Opera joined them. That would avoid some of the "WTF fonts > work everywhere except in Opera" recent messages you can easily find > with Google. I suspect this would be the correct thing to do for almost all programs, including opera. Text rendering (as opposed to glyph rendering, which is almost trivial) is truly a hard problem, and I think it would be highly beneficial if everyone used the same engine. Particularly because I suspect that user tweaking of the configuration will always be necessary. (I haven't looked at pango yet, so I have no idea if it is suitable for us (API or license-wise). And I don't work on the desktop browser either these days, so I don't know too much about what is happening there.) eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
