Re: Crash report

2009-01-04 Thread Michel Dänzer 
On Sun, 2009-01-04 at 17:58 +, d...@rdmp.org wrote:
> Just pulled everything from git, and now X crashes hard leaving me with a
> blank text screen except for a flashing cursor.  Presumably this is VT7,
> but the keyboard is inactive so I can't switch to a working console and
> have to alt-ctrl-del (that is the only thing that still seems to work).
> 
> The X server log file is attached.

It seems truncated, so maybe the X server dies to an unresolved symbol
or something like that. Check the stderr output.


-- 
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: [multiseat] hard freeze when running "X -arguments... :1"

2009-01-04 Thread Tomasz Chmielewski 
Tiago Vignatti schrieb:

>> So far I have one problem: my computer freezes whenever I want to use 
>> GDM as a desktop manager. On the other hand, everything works fine if 
>> I use KDM.
>>
>> Closer investigation turned up that the freeze does not really depend 
>> on the desktop manager, but on the order X servers are started.
> 
> Some days ago I answered to you in what mess we're living (search for 
> <494ee380.1040...@c3sl.ufpr.br>). You won't be able to initialize more 
> than one X server so soon.

"Not being able to initialize more than one X server" doesn't sound like 
a right direction of development to me, or?


> That's the reason why people is still using 
> nested servers (like Xephyr) under a multi-head Xorg to deploy the 
> multiseat model.


-- 
Tomasz Chmielewski
http://wpkg.org
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Don't alter device button maps in DoSetPointerMapping

2009-01-04 Thread Thomas Jaeger 
Sorry, forgot the attachment again...

> Thanks, that makes sense.  I'm attaching an updated patch that should
> cleanly apply after cherry-picking commit
> a85f0d6b98237d8a196de624207acf1983a1859a.

>From 6b57285d2f0274c6ef634a074b3881773c3bcf88 Mon Sep 17 00:00:00 2001
From: Thomas Jaeger 
Date: Sun, 4 Jan 2009 11:22:40 -0500
Subject: [PATCH] Don't alter device button maps in DoSetPointerMapping

Currently, if a device map differs from the core pointer map, then the
request may return MappingBusy, even though all the affected core
buttons are in the up state.
---
 dix/devices.c |   32 +---
 1 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/dix/devices.c b/dix/devices.c
index d84b57f..4b5ea94 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -1829,36 +1829,23 @@ static int
 DoSetPointerMapping(ClientPtr client, DeviceIntPtr device, BYTE *map, int n)
 {
 int rc, i = 0;
-DeviceIntPtr dev = NULL;
 
 if (!device || !device->button)
 return BadDevice;
 
-for (dev = inputInfo.devices; dev; dev = dev->next) {
-if ((dev->coreEvents || dev == inputInfo.pointer) && dev->button) {
-	rc = XaceHook(XACE_DEVICE_ACCESS, client, dev, DixManageAccess);
-	if (rc != Success)
-		return rc;
-	}
-}
+rc = XaceHook(XACE_DEVICE_ACCESS, client, device, DixManageAccess);
+if (rc != Success)
+return rc;
 
-for (dev = inputInfo.devices; dev; dev = dev->next) {
-if ((dev->coreEvents || dev == inputInfo.pointer) && dev->button) {
-for (i = 0; i < n; i++) {
-if ((device->button->map[i + 1] != map[i]) &&
-BitIsOn(device->button->down, i + 1)) {
-return MappingBusy;
-}
-}
+for (i = 0; i < n; i++) {
+if ((device->button->map[i + 1] != map[i]) &&
+BitIsOn(device->button->down, i + 1)) {
+return MappingBusy;
 }
 }
 
-for (dev = inputInfo.devices; dev; dev = dev->next) {
-if ((dev->coreEvents || dev == inputInfo.pointer) && dev->button) {
-for (i = 0; i < n; i++)
-dev->button->map[i + 1] = map[i];
-}
-}
+for (i = 0; i < n; i++)
+device->button->map[i + 1] = map[i];
 
 return Success;
 }
@@ -1915,7 +1902,6 @@ ProcSetPointerMapping(ClientPtr client)
 return Success;
 }
 
-/* FIXME: Send mapping notifies for all the extended devices as well. */
 SendMappingNotify(ptr, MappingPointer, 0, 0, client);
 WriteReplyToClient(client, sizeof(xSetPointerMappingReply), &rep);
 return Success;
-- 
1.6.0.4

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Don't alter device button maps in DoSetPointerMapping

2009-01-04 Thread Thomas Jaeger 
Peter Hutterer wrote:
> On Sun, Jan 04, 2009 at 11:31:47AM -0500, Thomas Jaeger wrote:
>> I think the current behavior violates the core spec: If, say, button 1
>> is pressed on a device where it is currently disabled, but it is mapped
>> to itself on the VCP, then an XSetPointerMapping request that doesn't
>> change the mapping of button 1 will nonetheless fail.
> 
> Oh right. AFAICT, this is a leftover for when we copied the SD into the MD
> each time the SD changes. In this case, the SD's button map would be merged
> into the MD, thus overwriting the last XSetPointerMapping request (unless said
> request is also applied to the SD).
> 
> We don't do that anymore now, and the MD in fact uses a standalone mapping, so
> the approach is good. However, see below:
>> @@ -1869,7 +1856,7 @@ ProcSetPointerMapping(ClientPtr client)
>>  BYTE *map;
>>  int ret;
>>  int i, j;
>> -DeviceIntPtr ptr = PickPointer(client);
>> +DeviceIntPtr ptr = inputInfo.pointer;
> 
> No. PickPointer must be used here, as it return's the client's ClientPointer.
> Hardcoding the VCP means that a client may change the button mapping of the
> wrong pointer. So while this approach would work for 1.6 and master in the
> single-pointer case, it breaks once a second MD is available.

Thanks, that makes sense.  I'm attaching an updated patch that should
cleanly apply after cherry-picking commit
a85f0d6b98237d8a196de624207acf1983a1859a.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Don't release passive grabs unless all buttons are up

2009-01-04 Thread Peter Hutterer 
On Sun, Dec 21, 2008 at 10:14:53PM +0100, Thomas Jaeger wrote:
> This turned out to be a little bit trickier than I initially thought,
> since buttonsDown counts the number of physical buttons that are down,
> before they are mapped to logical buttons.
> 
> The thing I'm unsure about (as should be evident from the patch), is
> where to stick the declaration for the new function AllButtonsAreUp.
> 
> Thanks,
> Tom
> 
> Thomas Jaeger wrote:
> > I can't see any reason why we would treat buttons > 5 differently.  This
> > patch simplifies client code by eliminating the need to call XGrabDevice
> > after a button has been pressed and prevents race conditions that could
> > result from that.


Following up on that:
Both the core protocol and the XI protocol spec state that a passive grab is
to be released when all buttons are logically up, regardless of modifiers.
This is where the magic number 5 comes in. Core allows for 5 buttons, XI
allows for more.

This puts us in a difficult position. Core requires us to release the grab if,
say, only button 6 is down. XI requires us to maintain the grab.
I think we need a more complex solution than the one you proposed: test
whether the passive grab is a core or an XI grab and release depending on this
condition.
Something like 
if ((grab->coreGrab && !button->state) && ... ||
(!grab->coreGrab && AllButtonsAreUp(b))

Keith, any opinions on this?

Cheers,
  Peter

> From 86c2f7e8c37532287772aae1c2554da5fd5eda86 Mon Sep 17 00:00:00 2001
> From: Thomas Jaeger 
> Date: Sat, 20 Dec 2008 16:17:02 +0100
> Subject: [PATCH] Don't release grabs unless all buttons are up
> 
> Previously, only buttons <= 5 would count here.
> ---
>  Xi/exevents.c  |2 +-
>  dix/devices.c  |   18 ++
>  dix/events.c   |2 +-
>  include/inputstr.h |3 +++
>  4 files changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/Xi/exevents.c b/Xi/exevents.c
> index 083bb2f..07b7341 100644
> --- a/Xi/exevents.c
> +++ b/Xi/exevents.c
> @@ -1069,7 +1069,7 @@ ProcessOtherEvent(xEventPtr xE, DeviceIntPtr device, 
> int count)
>   xE->u.u.detail = key;
>   return;
>   }
> -if (!b->state && device->deviceGrab.fromPassiveGrab)
> +if (device->deviceGrab.fromPassiveGrab && AllButtonsAreUp(b))
>  deactivateDeviceGrab = TRUE;
>  }
>  
> diff --git a/dix/devices.c b/dix/devices.c
> index d89f6c3..10dca2e 100644
> --- a/dix/devices.c
> +++ b/dix/devices.c
> @@ -1996,6 +1996,24 @@ NoteLedState(DeviceIntPtr keybd, int led, Bool on)
>   ctrl->leds &= ~((Leds)1 << (led - 1));
>  }
>  
> +Bool
> +AllButtonsAreUp(ButtonClassPtr butc)
> +{
> +int key;
> +int missingButtons = butc->buttonsDown;
> +
> +for (key = 0; missingButtons && key < butc->numButtons; key++)
> +{
> + int bit = 1 << (key & 7);
> + if (butc->down[key >> 3] & bit) {
> + if (butc->map[key])
> + return False;
> + missingButtons--;
> + }
> +}
> +return True;
> +}
> +
>  _X_EXPORT int
>  Ones(unsigned long mask) /* HACKMEM 169 */
>  {
> diff --git a/dix/events.c b/dix/events.c
> index d7618c2..0105e82 100644
> --- a/dix/events.c
> +++ b/dix/events.c
> @@ -3846,7 +3846,7 @@ ProcessPointerEvent (xEvent *xE, DeviceIntPtr mouse, 
> int count)
>   if (xE->u.u.detail == 0)
>   return;
>  filters[mouse->id][Motion_Filter(butc)] = MotionNotify;
> - if (!butc->state && mouse->deviceGrab.fromPassiveGrab)
> + if (mouse->deviceGrab.fromPassiveGrab && AllButtonsAreUp(butc))
>   deactivateGrab = TRUE;
>   break;
>   default:
> diff --git a/include/inputstr.h b/include/inputstr.h
> index 9591d2f..a94ea01 100644
> --- a/include/inputstr.h
> +++ b/include/inputstr.h
> @@ -200,6 +200,9 @@ typedef struct _ButtonClassRec {
>  #endif
>  } ButtonClassRec, *ButtonClassPtr;
>  
> +extern Bool AllButtonsAreUp(
> +ButtonClassPtr /*butc*/);
> +
>  typedef struct _FocusClassRec {
>  WindowPtrwin; /* May be set to a int constant (e.g. 
> PointerRootWin)! */
>  int  revert;
> -- 
> 1.5.6.3

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Don't alter device button maps in DoSetPointerMapping

2009-01-04 Thread Peter Hutterer 
On Sun, Jan 04, 2009 at 11:31:47AM -0500, Thomas Jaeger wrote:
> I think the current behavior violates the core spec: If, say, button 1
> is pressed on a device where it is currently disabled, but it is mapped
> to itself on the VCP, then an XSetPointerMapping request that doesn't
> change the mapping of button 1 will nonetheless fail.

Oh right. AFAICT, this is a leftover for when we copied the SD into the MD
each time the SD changes. In this case, the SD's button map would be merged
into the MD, thus overwriting the last XSetPointerMapping request (unless said
request is also applied to the SD).

We don't do that anymore now, and the MD in fact uses a standalone mapping, so
the approach is good. However, see below:

> From e021ca2981f6e01ff23523106ab42f73bcbe7308 Mon Sep 17 00:00:00 2001
> From: Thomas Jaeger 
> Date: Sun, 4 Jan 2009 11:22:40 -0500
> Subject: [PATCH] Don't alter device button maps in DoSetPointerMapping
> 
> Currently, if a device map differs from the core pointer map, then the
> request may return MappingBusy, even though all the affected core
> buttons are in the up state.
> ---
>  dix/devices.c |   34 ++
>  1 files changed, 10 insertions(+), 24 deletions(-)
> 
> diff --git a/dix/devices.c b/dix/devices.c
> index df6cd51..44a4f18 100644
> --- a/dix/devices.c
> +++ b/dix/devices.c
> @@ -1829,36 +1829,23 @@ static int
>  DoSetPointerMapping(ClientPtr client, DeviceIntPtr device, BYTE *map, int n)
>  {
>  int rc, i = 0;
> -DeviceIntPtr dev = NULL;
>  
>  if (!device || !device->button)
>  return BadDevice;
>  
> -for (dev = inputInfo.devices; dev; dev = dev->next) {
> -if ((dev->coreEvents || dev == inputInfo.pointer) && dev->button) {
> - rc = XaceHook(XACE_DEVICE_ACCESS, client, dev, DixManageAccess);
> - if (rc != Success)
> - return rc;
> - }
> -}
> +rc = XaceHook(XACE_DEVICE_ACCESS, client, device, DixManageAccess);
> +if (rc != Success)
> +return rc;
>  
> -for (dev = inputInfo.devices; dev; dev = dev->next) {
> -if ((dev->coreEvents || dev == inputInfo.pointer) && dev->button) {
> -for (i = 0; i < n; i++) {
> -if ((device->button->map[i + 1] != map[i]) &&
> -BitIsOn(device->button->down, i + 1)) {
> -return MappingBusy;
> -}
> -}
> +for (i = 0; i < n; i++) {
> +if ((device->button->map[i + 1] != map[i]) &&
> +BitIsOn(device->button->down, i + 1)) {
> +return MappingBusy;
>  }
>  }
>  
> -for (dev = inputInfo.devices; dev; dev = dev->next) {
> -if ((dev->coreEvents || dev == inputInfo.pointer) && dev->button) {
> -for (i = 0; i < n; i++)
> -dev->button->map[i + 1] = map[i];
> -}
> -}
> +for (i = 0; i < n; i++)
> +device->button->map[i + 1] = map[i];
>  
>  return Success;
>  }
> @@ -1869,7 +1856,7 @@ ProcSetPointerMapping(ClientPtr client)
>  BYTE *map;
>  int ret;
>  int i, j;
> -DeviceIntPtr ptr = PickPointer(client);
> +DeviceIntPtr ptr = inputInfo.pointer;

No. PickPointer must be used here, as it return's the client's ClientPointer.
Hardcoding the VCP means that a client may change the button mapping of the
wrong pointer. So while this approach would work for 1.6 and master in the
single-pointer case, it breaks once a second MD is available.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: multihead / dual input howto (two local users, keyboards etc.)?

2009-01-04 Thread Tiago Vignatti 
Peter Hutterer escreveu:
> I don't know what other people's view on this is but I'd certainly appreciate
> it if you could transcribe this to the xorg wiki. It seems the question of
> multi-seat comes up quite frequently and having a central location to point
> people at would be helpful.
> 
> Alternatively, a site on the xorg wiki just linking to various howto's on
> multi-seat configurations would be a good thing to have too. Currently, a
> search for multiseat does not show anything.

you're right, Peter. I just started a page with some information here. 
Anyone is very welcome to populate it:

 http://wiki.x.org/wiki/Development/Documentation/Multiseat


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: [multiseat] hard freeze when running "X -arguments... :1"

2009-01-04 Thread Tiago Vignatti 
Tomasz Chmielewski escreveu:
> I'm trying to write some easy to follow documentation about setting up 
> a multiseat workstation.

Oh no, don't do another one howto, please. (see my next email)


> So far I have one problem: my computer freezes whenever I want to use 
> GDM as a desktop manager. On the other hand, everything works fine if 
> I use KDM.
> 
> Closer investigation turned up that the freeze does not really depend 
> on the desktop manager, but on the order X servers are started.

Some days ago I answered to you in what mess we're living (search for 
<494ee380.1040...@c3sl.ufpr.br>). You won't be able to initialize more 
than one X server so soon. That's the reason why people is still using 
nested servers (like Xephyr) under a multi-head Xorg to deploy the 
multiseat model.


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: Please revert commit d21155a3e9b51df946766926bc6155c8972c4439.

2009-01-04 Thread Peter Hutterer 
On Sat, Jan 03, 2009 at 10:28:46PM -0500, Thomas Jaeger wrote:
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=d21155a3e9b51df946766926bc6155c8972c4439
> 
> Here's the correct link to the thread where this was previously discussed:
> http://lists.freedesktop.org/archives/xorg/2008-June/035943.html

> In current X servers, the button field is a bit mask, so functions such
> as XSetPointerMapping and XQueryDeviceState behave incorrectly right now.

http://cgit.freedesktop.org/xorg/xserver/patch/?id=a85f0d6b98237d8a196de624207acf1983a1859a

Looks like this needs to be cherry-picked. Can you confirm this please?

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xscope compilation error

2009-01-04 Thread Joel Feiner 
On a related note, how do you actually get xscope to work?  I've tried 
following the manpage but whenever I connect to xscope with a client, it 
causes xscope to die with the message: "Could not connect to Server" and 
the reason given (if the debug level is high enough) is "TransConnect() 
failed".

Sorry to hijack...

Samuel Thibault wrote:
> Rui Tiago Ca��o Matos, le Mon 05 Jan 2009 01:01:20 +, a �crit :
>> I got xscope from git://anongit.freedesktop.org/~alanc/xscope but it
>> doesn't compile:
>>
>> gcc -DHAVE_CONFIG_H -I.-D_BSD_SOURCE -DHAS_FCHOWN
>> -DHAS_STICKY_DIR_BIT   -DUSE_XTRANS -g -O2 -MT scope.o -MD -MP -MF
>> .deps/scope.Tpo -c -o scope.o scope.c
>> scope.c:73: error: 'MAXHOSTNAMELEN' undeclared here (not in a function)
>>
>> I believe that, in Linux, the right thing to do is to #include
>> 
>
> You should rather just #include, which doesn't depend on
> linuxness.  That being said, the code should rather be rewriten into not
> using MAXHOSTNAMELEN unconditionally, since some systems do not have
> such arbitrary limitation.
>
> Samuel
> ___
> 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: xscope compilation error

2009-01-04 Thread Samuel Thibault 
Rui Tiago Cação Matos, le Mon 05 Jan 2009 01:01:20 +, a écrit :
> I got xscope from git://anongit.freedesktop.org/~alanc/xscope but it
> doesn't compile:
> 
> gcc -DHAVE_CONFIG_H -I.-D_BSD_SOURCE -DHAS_FCHOWN
> -DHAS_STICKY_DIR_BIT   -DUSE_XTRANS -g -O2 -MT scope.o -MD -MP -MF
> .deps/scope.Tpo -c -o scope.o scope.c
> scope.c:73: error: 'MAXHOSTNAMELEN' undeclared here (not in a function)
> 
> I believe that, in Linux, the right thing to do is to #include
> 

You should rather just #include , which doesn't depend on
linuxness.  That being said, the code should rather be rewriten into not
using MAXHOSTNAMELEN unconditionally, since some systems do not have
such arbitrary limitation.

Samuel
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] dix: Fix handling of do_not_propagate_mask window attribute

2009-01-04 Thread Peter Hutterer 
On Fri, Dec 26, 2008 at 07:34:39AM +0100, Kim Woelders wrote:
> Hello,
>
> It looks like handling of the do_not_propagate_mask window attribute has  
> been broken at some point.
>
> Attached patch should fix that.

ACK. 

Please send me a git-formatted patch including a descriptive commit message
and I'll merge, test and push it.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

xscope compilation error

2009-01-04 Thread Rui Tiago Cação Matos 
Hi,

I got xscope from git://anongit.freedesktop.org/~alanc/xscope but it
doesn't compile:

gcc -DHAVE_CONFIG_H -I.-D_BSD_SOURCE -DHAS_FCHOWN
-DHAS_STICKY_DIR_BIT   -DUSE_XTRANS -g -O2 -MT scope.o -MD -MP -MF
.deps/scope.Tpo -c -o scope.o scope.c
scope.c:73: error: 'MAXHOSTNAMELEN' undeclared here (not in a function)

I believe that, in Linux, the right thing to do is to #include
 but as I consistently fail at getting the autotools to
do what I want I'm just reporting this without a patch, sorry.

Rui
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Mouse and KVM Issue

2009-01-04 Thread Peter Hutterer 
On Thu, Jan 01, 2009 at 12:34:50PM -0500, - gw1500se wrote:
> 
> I am having a problem with my Microsoft PS/2 optical wheel mouse when I
> switch between machines with a KVM switch. Specifically, my Mandriva machine
> no longer recognizes a mouse is attached (Windows does not have a problem
> with switching). Some research has come up with a suggestion that the mouse
> protocol be changed in xorg.conf to PS/2. However, it is currently
> ExplorerPS/2 and when I try to change it, it magically reverts so I don't
> know if that change will fix my problem or not.

what version of the server?
watch the xorg.log when you switch to and fro the machine, it'll probably
notice the mouse going away, but not coming back. In this case it could be
either a problem with the kernel or with HAL.

try adding "AutoAddDevices" "false" to you ServerLayout section and restart
the server. This forces the server to use the mouse driver (by default on
/dev/input/mice) and leave all the hotplugging to the kernel.
Does the mouse work then? If not - definitely a kernel problem.

> Perhaps someone can tell me either why the mouse protocol will not stay the
> way I set it or, better yet, why the mouse goes away after using the KVM
> switch.

most likely because your xorg.conf settings are ignored, as they usually are
with servers 1.5 and above.
http://who-t.blogspot.com/2008/12/evdev-xorgconf-hal-and-other-fud.html

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xsetpointer deprecated?

2009-01-04 Thread Peter Hutterer 
On Fri, Jan 02, 2009 at 12:32:52PM +0100, Philipp Kerling wrote:
> the xorg utility xsetpointer reports that it is deprecated for XInput
> versions >= 1.4. It still works fine even in newer ones. What exactly
> has been deprecated and what functions should be used instead?

xsetpointer changes options on the core pointer device. since 1.4, the core
pointer device is just a virtual device, with all physical devices hanging off
it. it is recommended that the physical devices are configured one-by-one
instead (try the "xinput" tool).

the problem with xsetpointer is simply that because it only knows about the
core pointer, it forces the core pointer configuration onto all other devices,
overwriting a per-device configuration.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: multihead / dual input howto (two local users, keyboards etc.)?

2009-01-04 Thread Peter Hutterer 
On Sun, Jan 04, 2009 at 11:12:58PM +0100, Tomasz Chmielewski wrote:
> Mader, Alexander (N-MSR) schrieb:
> > Tomasz Chmielewski schrieb:
> >> Does anyone know any up-to-date HOWTO for setting up multihead / dual 
> >> input - two graphics cards running on one PC, with two local users, 
> >> with two keyboards, running separate X sessions?
> 
> >> What I'm finding in the internet are either old / XFree based 
> >> documents, mostly incomplete etc.
> > 
> > Even if the guides are partly dated I found them useful.
> 
> I wrote a short guide on setting up a multiseat X workstation:
> 
> http://wpkg.org/Configuring_multiseat_X_workstation
> 
> 
> It covers xorg.conf setup (one file for all seats), GDM and KDM config, 
> some hardware suggestions, basic troubleshooting etc.

I don't know what other people's view on this is but I'd certainly appreciate
it if you could transcribe this to the xorg wiki. It seems the question of
multi-seat comes up quite frequently and having a central location to point
people at would be helpful.

Alternatively, a site on the xorg wiki just linking to various howto's on
multi-seat configurations would be a good thing to have too. Currently, a
search for multiseat does not show anything.

Cheers,
  Peter

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: multihead / dual input howto (two local users, keyboards etc.)?

2009-01-04 Thread Tomasz Chmielewski 
Mader, Alexander (N-MSR) schrieb:
> Tomasz Chmielewski schrieb:
>> Does anyone know any up-to-date HOWTO for setting up multihead / dual 
>> input - two graphics cards running on one PC, with two local users, 
>> with two keyboards, running separate X sessions?

>> What I'm finding in the internet are either old / XFree based 
>> documents, mostly incomplete etc.
> 
> Even if the guides are partly dated I found them useful.

I wrote a short guide on setting up a multiseat X workstation:

http://wpkg.org/Configuring_multiseat_X_workstation


It covers xorg.conf setup (one file for all seats), GDM and KDM config, 
some hardware suggestions, basic troubleshooting etc.

Feel free to comment ;)


-- 
Tomasz Chmielewski
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Crash report

2009-01-04 Thread dale 
Just pulled everything from git, and now X crashes hard leaving me with a
blank text screen except for a flashing cursor.  Presumably this is VT7,
but the keyboard is inactive so I can't switch to a working console and
have to alt-ctrl-del (that is the only thing that still seems to work).

The X server log file is attached.

Any ideas gratefully received.

Dale


_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/l2:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6

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.26 i686 
Current Operating System: Linux l2 2.6.26 #7 PREEMPT Thu Jul 31 18:42:47 BST 
2008 i686
Build Date: 04 January 2009  01:49:12PM
 
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: "/apps/x/var/log/Xorg.0.log", Time: Sun Jan  4 17:01:37 2009
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "X.org Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor[0]"
(**) |   |-->Device "Card0"
(**) |-->Input Device "Evdev mouse"
(**) Option "AllowEmptyInput" "false"
(==) Automatically adding devices
(==) Automatically enabling devices
(==) Including the default font path built-ins.
(**) FontPath set to:
/apps/x/lib/X11/fonts/75dpi:unscaled,
/apps/x/lib/X11/fonts/100dpi:unscaled,
/apps/x/lib/X11/fonts/cyrillic,
/apps/x/lib/X11/fonts/encodings,
/apps/x/lib/X11/fonts/misc,
/apps/x/lib/X11/fonts/OTF,
/apps/x/lib/X11/fonts/Speedo,
/apps/x/lib/X11/fonts/TTF,
/apps/x/lib/X11/fonts/Type1,
/apps/x/lib/X11/fonts/util,
built-ins
(**) ModulePath set to "/apps/x/lib/xorg/modules"
(==) |-->Input Device ""
(==) The core keyboard device wasn't specified explicitly in the layout.
Using the default keyboard configuration.
(II) Loader magic: 0x2bb0
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 5.0
X.Org XInput driver : 4.0
X.Org Server Extension : 2.0
(II) Loader running on linux
(--) using VT number 7

(--) PCI:*(0...@0:2:0) unknown vendor (0x8086) unknown chipset (0x2592) rev 4, 
Mem @ 0xd000/524288, 0xa000/268435456, 0xd008/262144, I/O @ 
0xe000/8
(--) PCI: (0...@0:2:1) unknown vendor (0x8086) unknown chipset (0x2792) rev 4, 
Mem @ 0xd010/524288
(II) Open ACPI successful (/var/run/acpid.socket)
(II) System resource ranges:
[0] -1  0   0x - 0x (0x1) MX[B]
[1] -1  0   0x000f - 0x000f (0x1) MX[B]
[2] -1  0   0x000c - 0x000e (0x3) MX[B]
[3] -1  0   0x - 0x0009 (0xa) MX[B]
[4] -1  0   0x - 0x (0x1) IX[B]
[5] -1  0   0x - 0x (0x1) IX[B]
(II) "extmod" will be loaded. This was enabled by default and also specified in 
the config file.
(II) "dbe" will be loaded. This was enabled by default and also specified in 
the config file.
(II) "glx" will be loaded. This was enabled by default and also specified in 
the config file.
(II) "dri" will be loaded. This was enabled by default and also specified in 
the config file.
(II) "dri2" will be loaded by default.
(II) LoadModule: "glx"
(II) Loading /apps/x/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 class: X.Org Server Extension, version 2.0
(==) AIGLX enabled
(==) Exporting typical set of GLX visuals
(II) Loading extension GLX
(II) LoadModule: "extmod"
(II) Loading /apps/x/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
compiled for 1.6.99.1, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "dbe"
(II) Loading /apps/x/lib/xorg/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org F

Crash report

2009-01-04 Thread dale 

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

xauth generate and the removal of XSECURITY

2009-01-04 Thread Matthieu Herrb 
Hi,

is there with XACE an equivalent of the 'generate' command of xauth?
-- 
Matthieu Herrb
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[multiseat] hard freeze when running "X -arguments... :1"

2009-01-04 Thread Tomasz Chmielewski 
I'm trying to write some easy to follow documentation about setting up 
a multiseat workstation.

So far I have one problem: my computer freezes whenever I want to use 
GDM as a desktop manager. On the other hand, everything works fine if 
I use KDM.

Closer investigation turned up that the freeze does not really depend 
on the desktop manager, but on the order X servers are started.

For example, if I boot the PC to the console, then start:

/usr/bin/Xorg -nolisten tcp -layout seat1 -sharevts -novtswitch -isolateDevice 
PCI:2:5:0 :1

The computer hard freezes. What's interesting, I can see a few first 
lines of the X server output and a blinking cursor, but that's about it.
There is nothing in the logs (even when the filesystem is mounted with 
"sync" option"), machine doesn't reboot even if I pass the kernel panic=10
parameter (so it's not a kernel panic), there is no reaction for key presses
(caps lock, ctrl+alt+del, ctrl+alt+backspace, sysrq+s, sysrq+b, sysrq+o etc.),
machine doesn't send any packets any more (i.e., ping to another machine
started from a different console).

And this is why GDM was freezing the computer as well, where KDM didn't: 
GDM starts X servers in a different order than KDM does.


This GDM config file will boot into a multiseat station:

[servers]
0=Standard0
1=Standard1

[server-Standard0]
name=Standard server 0
command=/usr/bin/Xorg -nolisten tcp -layout seat1 -sharevts -novtswitch 
-isolateDevice PCI:2:5:0

[server-Standard1]
name=Standard server 1
command=/usr/bin/Xorg -nolisten tcp -layout seat0 -sharevts -novtswitch 
-isolateDevice PCI:1:00:0


Where this one will hard-freeze the machine (note that the order of X servers 
is switched):

[servers]
0=Standard0
1=Standard1

[server-Standard0]
name=Standard server 0
command=/usr/bin/Xorg -nolisten tcp -layout seat0 -sharevts -novtswitch 
-isolateDevice PCI:1:00:0

[server-Standard1]
name=Standard server 1
command=/usr/bin/Xorg -nolisten tcp -layout seat1 -sharevts -novtswitch 
-isolateDevice PCI:2:5:0



I use xorg 1.4.2 and Linux kernel 2.6.28.
PCI:1:00:0 is AGP RV350 AR [Radeon 9600] card.
PCI:2:5:0 is PCI RV280 [Radeon 9200 PRO] (rev 01) card.

Ideas?


-- 
Tomasz Chmielewski
http://wpkg.org
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xrandr reports two preferred modes

2009-01-04 Thread Rui Tiago Cação Matos 
Antonio,

2009/1/4 Antonio Cardoso Martins :
> When i execute xrandr, he reports 2 preferred modes for my TMDS-1
> monitor, and selects 1024x768, when the monitor is actually 1680x1050.
> xorg.conf has only information for the LVDS monitor.

you should post the X server version you're using as well as the
driver you're using and its version too. It might save you some work
if you just attach a recent X server log.

Rui
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Don't alter device button maps in DoSetPointerMapping

2009-01-04 Thread Thomas Jaeger 
I think the current behavior violates the core spec: If, say, button 1
is pressed on a device where it is currently disabled, but it is mapped
to itself on the VCP, then an XSetPointerMapping request that doesn't
change the mapping of button 1 will nonetheless fail.

Thomas Jaeger wrote:
> The wrong checks are being performed which can lead to XInput grabs
> failing to work.  I'd argue, though, that remapping device buttons is
> wrong anyway, see my next email.

>From e021ca2981f6e01ff23523106ab42f73bcbe7308 Mon Sep 17 00:00:00 2001
From: Thomas Jaeger 
Date: Sun, 4 Jan 2009 11:22:40 -0500
Subject: [PATCH] Don't alter device button maps in DoSetPointerMapping

Currently, if a device map differs from the core pointer map, then the
request may return MappingBusy, even though all the affected core
buttons are in the up state.
---
 dix/devices.c |   34 ++
 1 files changed, 10 insertions(+), 24 deletions(-)

diff --git a/dix/devices.c b/dix/devices.c
index df6cd51..44a4f18 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -1829,36 +1829,23 @@ static int
 DoSetPointerMapping(ClientPtr client, DeviceIntPtr device, BYTE *map, int n)
 {
 int rc, i = 0;
-DeviceIntPtr dev = NULL;
 
 if (!device || !device->button)
 return BadDevice;
 
-for (dev = inputInfo.devices; dev; dev = dev->next) {
-if ((dev->coreEvents || dev == inputInfo.pointer) && dev->button) {
-	rc = XaceHook(XACE_DEVICE_ACCESS, client, dev, DixManageAccess);
-	if (rc != Success)
-		return rc;
-	}
-}
+rc = XaceHook(XACE_DEVICE_ACCESS, client, device, DixManageAccess);
+if (rc != Success)
+return rc;
 
-for (dev = inputInfo.devices; dev; dev = dev->next) {
-if ((dev->coreEvents || dev == inputInfo.pointer) && dev->button) {
-for (i = 0; i < n; i++) {
-if ((device->button->map[i + 1] != map[i]) &&
-BitIsOn(device->button->down, i + 1)) {
-return MappingBusy;
-}
-}
+for (i = 0; i < n; i++) {
+if ((device->button->map[i + 1] != map[i]) &&
+BitIsOn(device->button->down, i + 1)) {
+return MappingBusy;
 }
 }
 
-for (dev = inputInfo.devices; dev; dev = dev->next) {
-if ((dev->coreEvents || dev == inputInfo.pointer) && dev->button) {
-for (i = 0; i < n; i++)
-dev->button->map[i + 1] = map[i];
-}
-}
+for (i = 0; i < n; i++)
+device->button->map[i + 1] = map[i];
 
 return Success;
 }
@@ -1869,7 +1856,7 @@ ProcSetPointerMapping(ClientPtr client)
 BYTE *map;
 int ret;
 int i, j;
-DeviceIntPtr ptr = PickPointer(client);
+DeviceIntPtr ptr = inputInfo.pointer;
 xSetPointerMappingReply rep;
 REQUEST(xSetPointerMappingReq);
 REQUEST_AT_LEAST_SIZE(xSetPointerMappingReq);
@@ -1915,7 +1902,6 @@ ProcSetPointerMapping(ClientPtr client)
 return Success;
 }
 
-/* FIXME: Send mapping notifies for all the extended devices as well. */
 SendMappingNotify(ptr, MappingPointer, 0, 0, client);
 WriteReplyToClient(client, sizeof(xSetPointerMappingReply), &rep);
 return Success;
-- 
1.6.0.4

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Fix typo in DoSetPointerMapping

2009-01-04 Thread Thomas Jaeger 
The wrong checks are being performed which can lead to XInput grabs
failing to work.  I'd argue, though, that remapping device buttons is
wrong anyway, see my next email.
>From 5da6b7a5f67dcb0d3c7079230bafc9c2f59083d3 Mon Sep 17 00:00:00 2001
From: Thomas Jaeger 
Date: Sun, 4 Jan 2009 10:56:56 -0500
Subject: [PATCH] Fix typo in DoSetPointerMapping

---
 dix/devices.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/dix/devices.c b/dix/devices.c
index df6cd51..a798e18 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -1845,8 +1845,8 @@ DoSetPointerMapping(ClientPtr client, DeviceIntPtr device, BYTE *map, int n)
 for (dev = inputInfo.devices; dev; dev = dev->next) {
 if ((dev->coreEvents || dev == inputInfo.pointer) && dev->button) {
 for (i = 0; i < n; i++) {
-if ((device->button->map[i + 1] != map[i]) &&
-BitIsOn(device->button->down, i + 1)) {
+if ((dev->button->map[i + 1] != map[i]) &&
+BitIsOn(dev->button->down, i + 1)) {
 return MappingBusy;
 }
 }
-- 
1.6.0.4

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

xrandr reports two preferred modes

2009-01-04 Thread Antonio Cardoso Martins 
When i execute xrandr, he reports 2 preferred modes for my TMDS-1
monitor, and selects 1024x768, when the monitor is actually 1680x1050.
xorg.conf has only information for the LVDS monitor.

ant...@lifebook:~> xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2704 x 1050
VGA disconnected (normal left inverted right x axis y axis)
   1024x768_6060.0
LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis)
0mm x 0mm
   1024x768   60.0*+   85.0 75.0 70.1 60.0
   832x62474.6
   800x60085.1 72.2 75.0 60.3 56.2
   640x48085.0 72.8 75.0 59.9
   720x40085.0
   640x40085.1
   640x35085.1
TMDS-1 connected 1024x768+0+0 (normal left inverted right x axis y axis)
494mm x 320mm
   1024x768   75.1*+   75.0 70.1 60.0
   1680x1050  59.9 +
   1400x1050  60.0
   1280x1024  75.0 60.0 60.0
   1280x960   60.0 60.0
   1152x864   75.0 75.0
   832x62474.6
   800x60072.2 75.0 60.3 56.2
   640x48075.0 72.8 72.8 75.0 66.7 60.0 59.9
   720x40070.1
TV disconnected (normal left inverted right x axis y axis)

Is this working as you have originally expected?

Thank you

-- 
-
Antonio Cardoso Martins
digiplan...@gmail.com
antonio.cmart...@siemens.com
Homepage: http://digiplan.eu.org
-

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: gma950 + latest x11 + latest intel driver

2009-01-04 Thread Vasily Khoruzhick 
On 4 January 2009 05:14:39 Jin, Gordon wrote:
> The glxinfo shows correctly. I think you've been using libdrm master (or
> 2.4.3), right? Where did you get the quake3 demo? Is it shipped in your
> distribution or you installed it by yourself?
>
> Gordon

I'm using libdrm master
quake3 is from gentoo portage (with pak0.pk3 from windows version of quake3), 
four.dm_64 is located in /usr/share/games/quake3/baseq3/pak8.pk3. Btw, it's 
not quake3 problem, same situation with all 3D-applications.

Vasily


signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg