Re: Radeon Mobility X1600 texture garbage w/ compiz skydome
On Sun, 2008-09-21 at 08:27 -0700, Corbin Simpson wrote: Michel Dänzer wrote: On Sun, 2008-09-21 at 13:35 +0200, Soeren Sonnenburg wrote: [...] (**) RADEON(0): Option GARTSize 64 (**) RADEON(0): Option FBTexPercent 0 Try without these two options. For the former, values larger than 32 (which is also the default now) aren't handled correctly automatically for PCIe cards. For the latter, the Mesa r300 driver doesn't properly handle GART texturing, so it needs to have texture space in video RAM. For compiz, make sure your skydome isn't larger than MAX_TEX_SIZE/2 in any dimension. For your chipset, it would be 2048x2048. Any larger, and you'll get a very, um, fun skydome glitch. (Compiz doesn't properly check this...) Also, for UT2004, turning off FBTexPercent should do the trick. Yes it all works now and that poor windows users seeing these effects became incredibly jealous. Anyway as a consequence I've just ordered another ATI for my desktop :) Soeren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Raw mouse input is distorted
On Fri, Sep 19, 2008 at 01:29:58PM +0200, Søren Hauberg wrote: I do have a follow-up question (you can't get rid of me that easy :-) ). I have modified the 'usbtouchscreen' kernel module such that it can use calibration parameters. With this in place, my touchscreen works in X with the 'evdev' driver, i.e. out of the box. Do you guys think this is the right approach to handling touchscreens in GNU/Linux, or would you prefer an X driver for handling touchscreens? I plan on posting the kernel patch to the kernel list on Monday unless anybody here thinks the problem should be solved in X instead of the kernel. I'd prefer the fix in the kernel module, as it keeps the X drivers to a minimum. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Raw mouse input is distorted
Søren Hauberg wrote: I'm sorry but I don't quite understand (I don't know that much about either X, nor the kernel). But you think it would be better to solve this in X, right? Via a special driver for touch screens? And then I can use these 'device properties' to set the calibration parameters without restarting X? Is that what you mean? If so, where can I read about these 'device properties'? It depends on what exactly you are calibrating. If it is only about sensor value range, evdev will adapt to what the kernel specifies in EVIOCGABS (ABS_X / ABS_Y). Should suffice in the usual case. If there's more, well, it's really up to you. In-kernel means gpm stuff works too. As for dev props, peter's post is everything non-code I saw yet: http://who-t.blogspot.com/2008/07/input-device-properties.html ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Raw mouse input is distorted
2008/9/22 Peter Hutterer [EMAIL PROTECTED]: On Fri, Sep 19, 2008 at 01:29:58PM +0200, Søren Hauberg wrote: I do have a follow-up question (you can't get rid of me that easy :-) ). I have modified the 'usbtouchscreen' kernel module such that it can use calibration parameters. With this in place, my touchscreen works in X with the 'evdev' driver, i.e. out of the box. Do you guys think this is the right approach to handling touchscreens in GNU/Linux, or would you prefer an X driver for handling touchscreens? I plan on posting the kernel patch to the kernel list on Monday unless anybody here thinks the problem should be solved in X instead of the kernel. I'd prefer the fix in the kernel module, as it keeps the X drivers to a minimum. This is also the conclusion I came to, because the changes to the kernel are fairly small. Also, it should help touch screen users who aren't using X. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Keymap issues with Pointer+Keys device
On Tue, Sep 16, 2008 at 11:58:56AM +0200, Sascha Hlusiak wrote: BTW: With MPX, having two key devices attached to the first master device works fine, regarding the keymap. When creating a second master and attaching a keyboard to that, key presses seem to use the keymap of the first master device, so of the other keyboard. Note that if you're using core clients, this is intended behaviour. Remember that the ClientPointer (CP) always assigns a primary master device to a core client. So the call order is something like: Client requests keymap, server replies with CP's keymap. If you then hit a key on kbd 2, the server notifies the client that the keymap has changed. Client requests keymap, server replies with CP's keymap. oops. solution: fix the client :) Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Optimization idea: soft XvPutImage
--- On Mon, 9/22/08, Michel Dänzer [EMAIL PROTECTED] wrote: On Sun, 2008-09-21 at 13:58 +0200, Soeren Sandmann wrote: As other people pointed out, XRender does allow arbitrary 3x3 transformations of source images, but you are right that the XRender protocol would require putting the data in a drawable first. There could be a generic XVideo adaptor which uses RENDER internally. The Xgl code might already have something like that. Wow! Right you are. xorg-server-1.5/src/hw/xgl/xglxv.c. At first glance, at least, it looks like it should be readily portable for Xgl to fb, as the Xgl specific stuff appears to be contained mostly in well labelled macros. Thank you very much for pointing this out. Adam Richter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 0/3] X Input 1.5 device properties (final patches)
Here's the (hopefully) final patches to device properties in the server. As mentioned in [1], Configure/Query property functionality and requests have been culled. Patch 1 removes these requests. An updated inputproto is required as well of course. Patch 2 allows property handlers to return status codes instead of just TRUE/FALSE. These status codes (if != Success) are returned to the client as errors. Patch 3 asks handlers before the deletion of a property. This allows a handler to implement immutable properties. Updated inputproto and evdev patches that conform to this implementation are waiting and can be pushed. Documentation update is nearly there and will be pushed with the pack. Cheers, Peter [1] http://lists.freedesktop.org/archives/xorg/2008-September/038262.html ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 3/3] Xi: ask handlers before deletion of property.
From: Peter Hutterer [EMAIL PROTECTED]
Add delete parameter to SetProperty handler, handlers can refuse to delete a
property by returning something other than Success.
---
Xi/xiproperty.c| 20 ++--
dix/devices.c |6 +-
include/exevents.h |3 ++-
include/inputstr.h |3 ++-
4 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index bd130d1..50a4caf 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -96,7 +96,8 @@ long
XIRegisterPropertyHandler(DeviceIntPtr dev,
int (*SetProperty) (DeviceIntPtr dev,
Atom property,
- XIPropertyValuePtr prop),
+ XIPropertyValuePtr prop,
+ BOOL delete),
int (*GetProperty) (DeviceIntPtr dev,
Atom property))
{
@@ -218,11 +219,26 @@ XIDeleteDeviceProperty (DeviceIntPtr device, Atom
property, Bool fromClient)
{
XIPropertyPtr prop, *prev;
devicePropertyNotifyevent;
+int rc;
for (prev = device-properties.properties; (prop = *prev); prev =
(prop-next))
if (prop-propertyName == property)
break;
+/* Ask handlers if we may delete the property */
+if (fromClient device-properties.handlers)
+{
+XIPropertyHandlerPtr handler = device-properties.handlers;
+while(handler)
+{
+rc = handler-SetProperty(device, prop-propertyName,
+ prop-value, TRUE);
+if (rc != Success)
+return (rc);
+handler = handler-next;
+}
+}
+
if (prop)
{
*prev = prop-next;
@@ -329,7 +345,7 @@ XIChangeDeviceProperty (DeviceIntPtr dev, Atom property,
Atom type,
if (handler-SetProperty)
{
rc = handler-SetProperty(dev, prop-propertyName,
- new_value);
+ new_value, FALSE);
if (rc != Success)
{
if (new_value.data)
diff --git a/dix/devices.c b/dix/devices.c
index fb63473..c0ff019 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -102,10 +102,14 @@ DevPrivateKey UnusedClassesPrivateKey =
UnusedClassesPrivateKeyIndex;
* DIX property handler.
*/
static int
-DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop)
+DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop,
+ BOOL delete)
{
if (property == XIGetKnownProperty(XI_PROP_ENABLED))
{
+if (delete) /* you're not allowed to delete any server-internal prop */
+return BadAccess;
+
if (prop-format != 8 || prop-type != XA_INTEGER || prop-size != 1)
return BadValue;
diff --git a/include/exevents.h b/include/exevents.h
index c3a2ad6..b22d433 100644
--- a/include/exevents.h
+++ b/include/exevents.h
@@ -226,7 +226,8 @@ extern long XIRegisterPropertyHandler(
DeviceIntPtr dev,
int (*SetProperty) (DeviceIntPtr dev,
Atom property,
-XIPropertyValuePtr prop),
+XIPropertyValuePtr prop,
+BOOL delete),
int (*GetProperty) (DeviceIntPtr dev,
Atom property)
);
diff --git a/include/inputstr.h b/include/inputstr.h
index 93b3293..0a8bf91 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -366,7 +366,8 @@ typedef struct _XIPropertyHandler
long id;
int (*SetProperty) (DeviceIntPtr dev,
Atom property,
-XIPropertyValuePtr prop);
+XIPropertyValuePtr prop,
+BOOL delete);
int (*GetProperty) (DeviceIntPtr dev,
Atom property);
} XIPropertyHandler, *XIPropertyHandlerPtr;
--
1.5.4.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 3/3] Xi: ask handlers before deletion of property.
Hi Peter,
its good news you're done with that. A thing though:
-DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop)
+DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop,
+ BOOL delete)
{
if (property == XIGetKnownProperty(XI_PROP_ENABLED))
{
+if (delete) /* you're not allowed to delete any server-internal prop
*/
+return BadAccess;
+
Isn't that impossible anyway? If not, how about XI_PROP_MODE?
In general, I must admit I don't really get the scenario: Client props
don't have handlers, and server-side props can only be deleted by
in-server code, right?
So what problem does the patch solve, then?
Cheers,
Simon
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
what card is well supported? recommendations?
As I'm tired of constant fighting with nvidia (and nvidia obsoleted my current graphics card, GeForce FX 5200), I'm looking for a graphics card which has open drivers and is well supported. If it matters, I use 32 bit Linux. I looked a bit in X.org wiki, and it seems to me that Radeons with chipsets R400 should be sufficient for me. Unfortunately it's hard for me to find which chipset does a given Radeon card have (i.e. HD2400Pro - does it have R400 chipset?). I don't intent to play games, so 3D performance is not that important (it should suffice for desktop effects though). I'm looking for 2 cards. Card 1: - AGP - supports dual-head (DVI + VGA outputs) - proper 3D support - passive cooling (no fans) Card 2: - old plain PCI - proper 3D support - passive cooling (no fans) The intention is to put it into a multiseat workstation - where I currently have a GeForce FX 5200 (configured for TwinView/dual head) and an old SiS card. If possible, I'm looking for new, still produced cards. Do such cards exist? If so, do you have any recommendations? -- Tomasz Chmielewski http://wpkg.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
On Fri, 2008-09-19 at 16:55 -0700, Keith Packard wrote: On Fri, 2008-09-19 at 13:52 -0400, Adam Jackson wrote: You don't ask for the stipple though. It's the default. My point was that if you want to avoid the vintage X appearance, you'd likely start the X server with a black root window instead of the ugly stipple, and we could hook the 'disable the cursor' mode to the same option. Does that seem like a reasonable combination? I just can't imagine any credible desktop environment wanting either the stipple or the X cursor. The protocol, by the way, does _not_ mandate the stipple. It says that the initial contents are some unspecified two-color pattern made of blackPixel and whitePixel. There is a weasel argument here that having zero white pixels still counts as two color I guess. Even if you don't like that argument, we are the keepers of the spec, there's no reason we can't relax that requirement. Yes, I'm cool with the black root background; nicer looking, conforming to the spec and everything. Right then. -br is now the default. -retro gives you the old school root window and cursor behavior. I see a bike shed and I want to paint it black... - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Don't remap windows for SaveSetUnmap
On Fri, 2008-09-19 at 17:27 -0400, Owen Taylor wrote: I found that XFixesChangeSaveSet (..., SaveSetRoot, SaveSetUnmap); isn't working as expected ... when the client terminates, the save-set window will be reparented to the root window, but the window manager will get a MapRequest and map the window. Here's a fix to unmap the window before calling ReparentWindow(). Looks right to me. Applied, thanks! - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xkb: fix core keyboard map generation. #14373
On Mon, Sep 22, 2008 at 12:15:33PM +0930, Peter Hutterer wrote: According to Section 12.4 of the XKB Protocol Spec, if a key only has a single group but the keyboard has multiple groups defined, the core description of the key is a duplication of the single group across all symbols. i.e. G1L1 G1L2 G1L1 G1L2 G1L3 G1L4 G1L3 G1L4 The previous code generated G1L1 G1L2 G1L3 G1L4 G1L3 G1L4, leading to invented groups when the process is reversed. Note that this creates wrong key types on reconstruction from core to xkb, i.e. any single-group key with a key type that is not one of the canonical four (Sec 12.2.3), will get the assigned type on group 1, and a canonical type for the other gruops. X.Org Bug 14373 http://bugs.freedesktop.org/show_bug.cgi?id=14373 Nice catch! ACK to both patches, though untested. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building Xephyr
Yan Seiner wrote: I am new to building X. I'd like to take a shot at building Xephyr from git. I've been through the instructions on http://www.x.org/wiki/Development/git but xserver doesn't appear to have xephyr. Is there a list somewhere of what module contains which part? Where do I find xephyr? Xephyr is part of kdrive, itself part of xserver. Build it with configure --disable-xorg --disable-xinput --enable-kdrive --disable-dmx --disable-xnest --disable-xvfb -- Matthieu Herrb smime.p7s Description: S/MIME Cryptographic Signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
current git head of Xserver segfaults on a keyhit
Hello, the current git head of the Xserver segfaults on any keystroke. Trace is attached: (I have the core file and all the binaries, if interested) Core was generated by `/usr/local/X11R7.5/bin/Xorg :1.0'. Program terminated with signal 11, Segmentation fault. [New process 28180] #0 0x7f02c8b79c48 in _int_realloc () from /lib/libc.so.6 (gdb) where #0 0x7f02c8b79c48 in _int_realloc () from /lib/libc.so.6 #1 0x7f02c8b7ab6e in realloc () from /lib/libc.so.6 #2 0x00540cb2 in Xrealloc (ptr=0x2693e50, amount=744) at utils.c:1160 #3 0x005dc5e0 in _XkbCopyServerMap (src=0x265a050, dst=0x268c1c0) at xkbUtils.c:1230 #4 0x005def67 in XkbCopyKeymap (src=0x265a050, dst=0x268c1c0, sendNotifies=1) at xkbUtils.c:2089 #5 0x005a8935 in CopyKeyClass (device=0x26f0a00, master=0x262fc80) at exevents.c:225 #6 0x005a96cc in DeepCopyDeviceClasses (from=0x26f0a00, to=0x262fc80) at exevents.c:547 #7 0x005aa025 in ChangeMasterDeviceClasses (device=0x26f0a00, dcce=0x26976b0) at exevents.c:740 #8 0x005aa0f7 in UpdateDeviceState (device=0x26f0a00, xE=0x26976b0, count=1) at exevents.c:784 #9 0x005aac7b in ProcessOtherEvent (xE=0x26976b0, device=0x26f0a00, count=1) at exevents.c:1002 #10 0x005f190e in ProcessKeyboardEvent (xE=0x26976b0, keybd=0x26f0a00, count=1) at xkbPrKeyEv.c:209 #11 0x00511132 in mieqProcessInputEvents () at mieq.c:372 #12 0x0049d836 in ProcessInputEvents () at xf86Events.c:200 #13 0x0044f20b in Dispatch () at dispatch.c:363 #14 0x0043305b in main (argc=2, argv=0x7fffd34d2cd8, envp=0x7fffd34d2cf0) at main.c:390 -- Lukáš Hejtmánek ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current intel from git + xserver 1.5.0 + FreeBSD
On Mon, 22 Sep 2008 14:09:45 -0400 Adam K Kirchhoff [EMAIL PROTECTED] wrote: I'm trying to get that combination working on my i915 laptop, but I'm running into a problem... Namely, Xorg is crashing: X.Org X Server 1.5.0 Release Date: X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.1-PRERELEASE i386 Current Operating System: FreeBSD scroll.ashke.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sun Sep 21 11:28:25 EDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 22 September 2008 01:19:11PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Mon Sep 22 14:06:12 2008 (==) Using config file: /etc/X11/xorg.conf (EE) module ABI major version (0) doesn't match the server's version (1) (EE) Failed to load module record (module requirement mismatch, 0) (EE) module ABI major version (0) doesn't match the server's version (1) (EE) Failed to load module xtrap (module requirement mismatch, 0) (EE) intel(0): Failed to initialize kernel memory manager Fatal server error: Caught signal 11. Server aborting Now I'm assuming that the record and xtrap errors are not fatal, and I'm not sure if the lack of the kernel memory manager would be causing the crash, either. A backtrace shows: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x8201100 (LWP 100094)] 0x286af754 in i830_init_bufmgr (pScrn=0x8206800) at i830_driver.c:2915 2915 pI830-bufmgr = intel_bufmgr_fake_init(pI830-drmSubFD, (gdb) bt #0 0x286af754 in i830_init_bufmgr (pScrn=0x8206800) at #i830_driver.c:2915 1 0x286b7e33 in i830_allocator_init #(pScrn=0x8206800, offset=0, size=268435456) at i830_memory.c:504 2 #0x286b05bb in I830ScreenInit (scrnIndex=0, pScreen=0x823c4e0, argc=1, #argv=0xbfbfec2c) at i830_driver.c:2834 #3 0x0806b08d in AddScreen (pfnInit=0x286b01c0 I830ScreenInit, #argc=1, argv=0xbfbfec2c) at main.c:746 4 0x080a18fc in InitOutput #(pScreenInfo=0x81e3c20, argc=1, argv=0xbfbfec2c) at xf86Init.c:1051 5 #0x0806b7eb in main (argc=1, argv=0xbfbfec2c, envp=0xbfbfec34) at #main.c:358 Is there any way to get this working? Adam FYI, I narrowed it down some... c2f0df4dc97c87539b66525a277c7d1e2c421f61 is good: Merge branch 'drm-gem' of ssh://git.freedesktop.org/git/xorg/driver/xf86-video-intel into drm-gem (Jesse Barnes) 12df8f40d2fb41f5446db1b49beeb442da18bee2 is bad: Use dri_bo for all object allocations, including pixmaps under uxa (Keith Packard) None of the three in between build for me: 4cc20b7f6e25f4be4598f8edbe0077117126b4ee Don't call sync on prepare_access -- just let the driver deal with it. b0b0998b5d52d105eb1e631f688aa8f1bd55ef39 Make EXA functions work for UXA as well 59774e9aca2d743e82d616bb644d20ff6d60d492 Add UXA - the unified memory acceleration architecture. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current intel from git + xserver 1.5.0 + FreeBSD
On Mon, 22 Sep 2008 18:02:25 -0400 Adam K Kirchhoff [EMAIL PROTECTED] wrote: On Mon, 22 Sep 2008 14:09:45 -0400 Adam K Kirchhoff [EMAIL PROTECTED] wrote: I'm trying to get that combination working on my i915 laptop, but I'm running into a problem... Namely, Xorg is crashing: X.Org X Server 1.5.0 Release Date: X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.1-PRERELEASE i386 Current Operating System: FreeBSD scroll.ashke.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sun Sep 21 11:28:25 EDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 22 September 2008 01:19:11PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Mon Sep 22 14:06:12 2008 (==) Using config file: /etc/X11/xorg.conf (EE) module ABI major version (0) doesn't match the server's version (1) (EE) Failed to load module record (module requirement mismatch, 0) (EE) module ABI major version (0) doesn't match the server's version (1) (EE) Failed to load module xtrap (module requirement mismatch, 0) (EE) intel(0): Failed to initialize kernel memory manager Fatal server error: Caught signal 11. Server aborting Now I'm assuming that the record and xtrap errors are not fatal, and I'm not sure if the lack of the kernel memory manager would be causing the crash, either. A backtrace shows: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x8201100 (LWP 100094)] 0x286af754 in i830_init_bufmgr (pScrn=0x8206800) at i830_driver.c:2915 2915 pI830-bufmgr = intel_bufmgr_fake_init(pI830-drmSubFD, (gdb) bt #0 0x286af754 in i830_init_bufmgr (pScrn=0x8206800) at #i830_driver.c:2915 1 0x286b7e33 in i830_allocator_init #(pScrn=0x8206800, offset=0, size=268435456) at i830_memory.c:504 2 #0x286b05bb in I830ScreenInit (scrnIndex=0, pScreen=0x823c4e0, #argc=1, argv=0xbfbfec2c) at i830_driver.c:2834 #3 0x0806b08d in AddScreen (pfnInit=0x286b01c0 I830ScreenInit, #argc=1, argv=0xbfbfec2c) at main.c:746 4 0x080a18fc in InitOutput #(pScreenInfo=0x81e3c20, argc=1, argv=0xbfbfec2c) at #xf86Init.c:1051 5 0x0806b7eb in main (argc=1, argv=0xbfbfec2c, #envp=0xbfbfec34) at main.c:358 Is there any way to get this working? Adam FYI, I narrowed it down some... c2f0df4dc97c87539b66525a277c7d1e2c421f61 is good: Merge branch 'drm-gem' of ssh://git.freedesktop.org/git/xorg/driver/xf86-video-intel into drm-gem (Jesse Barnes) 12df8f40d2fb41f5446db1b49beeb442da18bee2 is bad: Use dri_bo for all object allocations, including pixmaps under uxa (Keith Packard) None of the three in between build for me: 4cc20b7f6e25f4be4598f8edbe0077117126b4ee Don't call sync on prepare_access -- just let the driver deal with it. b0b0998b5d52d105eb1e631f688aa8f1bd55ef39 Make EXA functions work for UXA as well 59774e9aca2d743e82d616bb644d20ff6d60d492 Add UXA - the unified memory acceleration architecture. Adam Well it looks like 'good' is not so good. Upon starting compiz, Xorg crashes again: Failed to initialize TTM buffer manager. Falling back to classic. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x8201100 (LWP 100142)] 0x28686edb in dri_bufmgr_check_aperture_space (bo_array=0x86fb220, count=1) at dri_bufmgr.c:140 140 return bo_array [0]-bufmgr-check_aperture_space(bo_array, count); (gdb) bt #0 0x28686edb in dri_bufmgr_check_aperture_space (bo_array=0x86fb220, #count=1) at dri_bufmgr.c:140 1 0x388f068d in intel_batchbuffer_reset #(batch=0x86f8fa0) at intel_batchbuffer.c:92 2 0x388f0b61 in #intel_batchbuffer_alloc (intel=0x855) at intel_batchbuffer.c:103 #3 0x3890aace in intelInitContext (intel=0x855, mesaVis=0x828b830, #driContextPriv=0x86f8ea0, sharedContextPrivate=0x0, #functions=0xbfbfe724) at intel_context.c:675 4 0x388fd16e in #i915CreateContext (mesaVis=0x828b830, driContextPriv=0x86f8ea0, #sharedContextPrivate=0x0) at i915_context.c:127 5 0x3890faef in #intelCreateContext (mesaVis=0x828b830, driContextPriv=0x86f8ea0, #sharedContextPrivate=0x0) at intel_screen.c:648 6 0x388e223d in #driCreateNewContext (psp=0x829a120, config=0x828b830, render_type=0, #shared=0x0, hwContext=17, data=0x8211da0) at ../common/dri_util.c:713 #7 0x28666286 in __glXDRIscreenCreateContext (baseScreen=0x8235540, #glxConfig=0x828c6d0, baseShareContext=0x0) at glxdri.c:652 8 #0x2865a042 in DoCreateContext (cl=Variable cl is not available. ) at glxcmds.c:238 #9 0x2865a2a5 in __glXDisp_CreateContext (cl=0x86d1bfc, pc=0x86f6c30 #\232\003\006) at glxcmds.c:287 10 0x2865c266 in __glXDispatch #(client=0x821c5e0) at
Re: Building X
Hi, On Mon, Sep 22, 2008 at 10:56:03AM -0400, Adam Jackson wrote: Right then. -br is now the default. -retro gives you the old school root window and cursor behavior. I don't understand why you don't leave the default as it was. Sureley the only situation where it is inconvenient to have to pass options explicitely, is when starting the server by hand for testing purposes -- and this is precisely the situation where both the weave and the cursor are useful... I see a bike shed and I want to paint it black... It's funny that you openly admit it's just a matter of taste, and yet seem set on changing the default for no good reason... Well, have fun dealing with all the bug reports from users wondering where the background/cursor has gone. -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
Problem: Many[1] users have killed X by accident.[2] Solution idea: Make it harder to kill X by accident. E.g. you could change the key sequence users must press. * Maybe require Control+Alt+Backspace then Control-Alt-Y.[3] * Or require Control+K+X pressed simultaneously. What do you think? Should Xorg change this key sequence? Please vote yes or no. You can add comments too. If you reply only to me by private mail, I will eventually summarize your reply to the list. Regards, -Jason ^ [1]. See http://bugs.freedesktop.org/show_bug.cgi?id=10510 then scroll down to the == Example evidence == section. Or see http://www.google.com/search?q=accidentally+hit+%7C+press+%7C+hitting+%7C+pressing+control+%7C+ctrl+alt+backspace+x%7Cxorg ^ [2]. I filed a bug about this last year but it's still untriaged. So now I'm asking here. It's bug 10510 (Xorg should use a more unlikely key combination than Control-Alt-Backspace as the server zap key): http://bugs.freedesktop.org/show_bug.cgi?id=10510 ^ [3]. After Control+Alt+Backspace, the PC speaker would beep once, the keyboard LEDs would blink a few times, and X would attempt to show a warning dialog. Thanks to Elisée Maurer at http://bugs.freedesktop.org/show_bug.cgi?id=10510#c1 for the warning-dialog idea. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
Igor Mozolevsky igor at hybrid-lab.co.uk writes: CTRL+ALT+BACKSPACE is just the way to do it OK. That's one no vote, duly noted. Thank you for your vote. I will now respond to the rest of your comments. just because users incompetently press the combination, doesn't mean it's a bad one. I respectfully disagree. Accidental zaps often cause data loss. Data loss is always unacceptable and Xorg should do whatever it takes to prevent it. Besides, pressing that combo requires some effort, I really can't see how one could do it accidentally! Please see http://bugs.freedesktop.org/show_bug.cgi?id=10510 then scroll down to the == Example evidence == section. Or see http://www.google.com/search?q=accidentally+hit+%7C+press+%7C+hitting+%7C+pressing+control+%7C+ctrl+alt+backspace+x%7Cxorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
Jason Spiro escreveu: Problem: Many[1] users have killed X by accident.[2] Solution idea: Make it harder to kill X by accident. E.g. you could change the key sequence users must press. * Maybe require Control+Alt+Backspace then Control-Alt-Y.[3] * Or require Control+K+X pressed simultaneously. The DontZap option in xorg.conf isn't enough for you? `man 5 xorg.conf` Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Spiro wrote: Problem: Many[1] users have killed X by accident.[2] Solution idea: Make it harder to kill X by accident. E.g. you could change the key sequence users must press. * Maybe require Control+Alt+Backspace then Control-Alt-Y.[3] * Or require Control+K+X pressed simultaneously. What do you think? Should Xorg change this key sequence? Please vote yes or no. You can add comments too. If you reply only to me by private mail, I will eventually summarize your reply to the list. Seems like it's a problem with emacs. Sure glad I use vi. :3 Seriously, no. Zap once, learn forever. No different than anything else, really; ever heard of press Alt+F4 to make it go faster? ~ C. - -- ~ Corbin Simpson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjYYdMACgkQeCCY8PC5utCneQCeObXX+/9MERbrN3xo41h40Niq u8UAn2Y3U2VWSwV4irduJp1UMm1t31fn =OZ96 -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
2008/9/23 Jason Spiro [EMAIL PROTECTED]: Igor Mozolevsky igor at hybrid-lab.co.uk writes: just because users incompetently press the combination, doesn't mean it's a bad one. I respectfully disagree. Accidental zaps often cause data loss. Data loss is always unacceptable and Xorg should do whatever it takes to prevent it. Pushing the reset button or pulling the cable from the wall also causes data loss, but you don't see flip covers protecting the reset buttons nor are the power cables welded into the wall at one end and the unit at the other. Unfortunately, there's no cure for human stupidity ;-) Doesn't CTRL+ALT+DELETE reboot the machine unconditionally? -- Igor ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
Igor Mozolevsky igor at hybrid-lab.co.uk wrote: ... Unfortunately, there's no cure for human stupidity There's no cure, but there are workarounds. Doesn't CTRL+ALT+DELETE reboot the machine unconditionally? Not usually. It used to reboot unconditionally way back. But, fifteen years ago, when Windows 3.1 came out[1], Microsoft changed things so that Windows users must press it twice to reboot. I suspect they did so to make it harder to lose data by accident. In Linux, Ctrl-Alt-Del reboots unconditionally only in console mode. Only expert users use console mode. When X is running, on all my Linux machines, Ctrl-Alt-Del brings up a shutdown-or-reboot? dialog instead. The vast majority of Linux users run X. ^ [1]. http://en.wikipedia.org/wiki/Control-Alt-Delete ; full disclosure: the Control-Alt-Delete detection feature required a 386 computer to work. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
Corbin Simpson mostawesomedude at gmail.com writes: ... Seriously, no. Your vote has been duly noted. Zap once, learn forever. No different than anything else, really; I still believe that Xorg should make it harder to make the mistake of an accidental zap. ever heard of press Alt+F4 to make it go faster? Yes. Note, though, that Firefox now displays a confirmation dialog when you try to quit when there are multiple tabs open. That featureis a good protection against the press Alt+F4 to make it go faster jokesters. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Spiro wrote: Corbin Simpson mostawesomedude at gmail.com writes: ... Seriously, no. Your vote has been duly noted. Zap once, learn forever. No different than anything else, really; I still believe that Xorg should make it harder to make the mistake of an accidental zap. ever heard of press Alt+F4 to make it go faster? Yes. Note, though, that Firefox now displays a confirmation dialog when you try to quit when there are multiple tabs open. That featureis a good protection against the press Alt+F4 to make it go faster jokesters. AIM, StarCraft, Dreamweaver... those were the things of my youth, and they all died when Alt+F4 was pressed. Consequently, I got *very* good at not casually pressing those two buttons together except when I really meant to do it. That's all. Need sleeps now. ~ C. - -- ~ Corbin Simpson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjYaeoACgkQeCCY8PC5utBKwgCfXOhawfMNm2gW0sq5Q9fndk7j olIAnjp9idMQETU0cSTUuoaRFr1pNn0N =fSQQ -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
On Tue, Sep 23, 2008 at 02:41:16AM +, Jason Spiro wrote: Problem: Many[1] users have killed X by accident.[2] Solution idea: Make it harder to kill X by accident. E.g. you could change the key sequence users must press. * Maybe require Control+Alt+Backspace then Control-Alt-Y.[3] * Or require Control+K+X pressed simultaneously. driver kbd: hardcodes Ctrl + Alt + Backspace. (IMHO that's a bug anyway) driver evdev: the XKB map decides what happens. In the latter case, all you have to do is change the xkb map. If you can convice svu to add it to xkeyboard-config, you only need to supply the right option and you're done with it. I'm not quite sure what the poll will achieve here. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to implement alternate zap key idea (was: Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to?something harder for users to press by accident?)
On Tue, Sep 23, 2008 at 04:39:49AM +, Jason Spiro wrote: Thanks for the info. 1. So I guess when using evdev, a way to implement my Ctrl+Alt+Bksp then Ctrl+Alt+Y idea would be this?: Ctrl+Alt+Bksp should latch some new modifier called ctrl_alt_bksp_was_pressed, and Ctrl+Alt+Y should zap X only when that modifier is latched. Would that work? maybe. You'd need to look at XKB's compat capabilities there. Anyway - that's taking the hard way out. your claim was that CAB is too easy to hit. So disable it - it could be easily done at runtime through xkb options. Or put it on ctrl-alt-shift-F12 or something. Alternatively, have a client listen to CAB, load the normal xkb behaviour, pop up a dialog if you want to kill the server, hit CAB now. (this is just idle thinking) As for the Ctrl+K+X idea (which I don't know is as safe; AFAIK, XKB will only handle combinations with modifiers. sequential key combos must be done in a client. 2. is it possible that a heavy pet sitting on the keyboard and depressing all keys at once could cause X to think Ctrl+K+X was pressed?), yes. and those users with a pet octopus better choose a 9-key combo. Ha, serves them octopodiformes right for having 2 fingers less than us! There is a thing such as cost/effort. stop your pet sitting on the keyboard, or disable zap. 3. are kbd and evdev each able to detect such a key combination? both are designed to handle key events - yes. 4. Are the majority of PS/2 and USB keyboards able to transmit such three-key combos reliably? they are designed to handle keyboard entry - yes. 5. Do most users know how to press multi-letter key combinations? Depends on your definition of most and of users. I know a fair few that would go looking for a post box when you start talking about multi-letter combinations. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to implement alternate zap key idea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Spiro wrote: Plus, due to the psychological effect called groupthink, people who would have said yes are now less likely to admit it to the entire list, since IIRC three have already said no and only one (me) has said yes. :( Ctrl+K+X may not work on some keyboards. Ctrl+Alt+Z, Ctrl+Alt+A, Ctrl+Alt+P may be a legitimate sequence in some program. We are not talking about a reboot, we are talking about killing, and optionally restarting, the graphics subsystem. This is not something any casual user should *ever* have to do. Ever. If somebody *needs* to kill X using an emergency key combo, and they are not devs, then something is wrong somewhere down the line. Or, to put it another way, distros should default to DontZap, except for Gentoo. :3 (And Slackware, and Arch, and LFS. Sheesh.) ~ C. - -- ~ Corbin Simpson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjYew0ACgkQeCCY8PC5utDzDQCdHD8WAk25da2bYerVQiUX1UnZ 5VkAn1xPsLSMnYgqdMJjQMIMTeUgrhxA =p2mD -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
