Re: pointer acceleration property rename and docs

[Fernando Carrijo]

Hi Simon,

Here's a couple of typos to be corrected before they go upstream.

On Wed, 06 Jan 2010 20:27:34 +0100, Simon Thum  wrote:
> From 920c13502f8184c18a0e7e6f362f0b5a75463267 Mon Sep 17 00:00:00 2001
> From: Simon Thum 
> Date: Wed, 6 Jan 2010 19:43:59 +0100
> Subject: [PATCH 3/5] xfree86: document pointer acceleration in xorg.conf.man
> 
> ---
>  hw/xfree86/doc/man/xorg.conf.man.pre |   44 
> ++
>  1 files changed, 44 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/xfree86/doc/man/xorg.conf.man.pre 
> b/hw/xfree86/doc/man/xorg.conf.man.pre
> index 9420dfe..1b88ecb 100644
> --- a/hw/xfree86/doc/man/xorg.conf.man.pre
> +++ b/hw/xfree86/doc/man/xorg.conf.man.pre
> @@ -915,6 +915,50 @@ may be reattached or set floating at runtime.
>  .TP 7
>  .BI "Option \*qSendDragEvents\*q  \*q" boolean \*q
>  Send core events while dragging. Enabled by default.
> +.PP
> +For pointing devices, the following options control how the pointer
> +is accelerated or decelerated with respect to physical device motion. Most of
> +these can be adjusted at runtime, see the xinput(1) man page for details. 
> Only
> +the most important acceleration options are discussed here.
> +.TP 7
> +.BI "Option \*qAccelerationProfile\*q  \*q" integer \*q
> +Select the profile, which determines actual acceleration as a function of
> +device velocity and acceleration controls (acceleartion and threshold, dubbed
  

> +pointer feedback). This is mainly a matter of personal preference.
> +.PP
> +.RS 6
> +.nf
> +.B  " 0  classic (mostly compatible)"
> +.B  "-1  none (only constant deceleration is applied)"
> +.B  " 1  device-dependent"
> +.B  " 2  polynomial (polynomial function)"
> +.B  " 3  smooth linear (hockey)"
> +.B  " 4  simple (normal wehn slow, then accelerated)"
   

> +.B  " 5  power (power function)"
> +.B  " 6  linear (more speed, more acceleration)"
> +.B  " 7  limited (like linear, but maxes out at threshold)"

Cheers,
Fernando Carrijo.

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

Re: Xorg crashes...

[Ryan Daly]

On 01/06/2010 10:26 PM, Justin P. Mattock wrote:
> the module should work.. hopefully their the same arch's
> 
> as for the next step:
> try starting the server from a TTY instead of through gdm
> (as stated by peter hutterer from the other post try this and then go 
> from there).
> 
> keep in mind evdev might be fine, at this point it could be
> anything.(so hopefully doing the above gives some useful info
> to target the problem).

Yep.  A 'uname -m' reports i686 on both systems and a 'file' on 
evdev_drv.so reports both are identical (only I didn't strip mine).

I will start the server from a tty and see what happens.  The system in 
question is at work, so I won't be doing anything more on this until 
tomorrow.  Thanks very much for the help you've given so far.  I'll post 
an update when I have one.


This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information.  If you are not the
intended recipient, notify the sender immediately and delete
this message.  Publication, reproduction, forwarding, or 
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392

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

Re: Xorg crashes...

[Justin P. Mattock]

On 01/06/10 19:17, Ryan Daly wrote:
> On 01/06/2010 09:39 PM, Justin P. Mattock wrote:
>>   you need a newer version of xmacros
>> (everything is at cgit.freedesktop.org)
>
> Got'em and installed in /usr/local.
>
>> hopefully ubuntu is up-to-date
>> i.g. hopefully it doesn't take
>> much to use the latest version.
>> (you can also grab the tar ball
>> there if it becomes too much, or try older
>> versions of ubuntu's package);
>>
>> hard part right I see is pinpointing what exactly
>> is exiting your server, so you don't have to
>> do the trial and error approach.
>
> I got a clean compile after using the latest version of the macros.
>
> I compiled on a separate x86 system, but the same version of Ubuntu.
> Can I take xf86-input-evdev/src/.libs/evdev_drv.so and simply copy that
> to /usr/lib/xorg/modules/input/evdev_drv.so (the Ubuntu location) on the
> troubled system and restart X?
   Should I continue to run w/ GDB attached
> to obtain another backtrace?
>
>

the module should work.. hopefully their the same arch's

as for the next step:
try starting the server from a TTY instead of through gdm
(as stated by peter hutterer from the other post try this and then go 
from there).

keep in mind evdev might be fine, at this point it could be
anything.(so hopefully doing the above gives some useful info
to target the problem).

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

Re: Xorg crashes...

[Peter Hutterer]

On Wed, Jan 06, 2010 at 09:25:43PM -0500, Ryan Daly wrote:
> On 01/06/2010 08:47 PM, Peter Hutterer wrote:
> >> Right, but it's nothing I'm doing.  That's the problem.  I'm not 
> >> initiating an exit, nor am I hitting ctrl-backspace (I don't think 
> >> that's enabled by default any longer anyway).
> >>
> >> I'm looking for suggestions as to WHAT may be causing the SIGTERM.
> > 
> > either your session is terminating for some reason or another or you might
> > be getting an unresolved symbol error. that terminates the server as well.
> > try starting the server from a TTY instead of through gdm, once it exits you
> > can see if it complains about a symbol error.
> 
> I'll definitely try this...but wouldn't any symbol errors appear in the 
> gdb output that I captured?

no. fwiw, I've had this happen to me just the other day and gdb didn't complain
at all.

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

Re: X11 XTEST Error when starting Xine

[Jim Duda]

On 01/05/2010 02:57 AM, Daniel Stone wrote:
> On Mon, Jan 04, 2010 at 10:54:00PM -0500, Jim Duda wrote:
>> Thanks for the post Dan.
>>
>> I tried both of these, removing XKeysymDB and rebuilding libX11.
>> Unfortunately, neither of these worked.  I get the same errors.
>> The version I downloaded was more recent that the version which
>> comes with fedora 11.
>
> Weird. Could you attach the output from all of the below, for both
> working and broken?
> $ locale
> $ strace ./keycode
> $ xkbcomp -xkb :0 foo
> $ xmodmap -pk
>
> Cheers,
> Daniel

Daniel,

Wow, thanks for the help.  Much appreciated.  Here is the dump below.
xmodmap appears to be empty, that cannot be good.

Jim

lroom# locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
lroom# strace ./keycode
execve("./keycode", ["./keycode"], [/* 35 vars */]) = 0
brk(0)  = 0x804a000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=80761, ...}) = 0
mmap2(NULL, 80761, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fb8000
close(3)= 0
open("/usr/local/lib/libX11.so.6", O_RDONLY) = 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20B\1\0004\0\0\0"..., 
512) = 512
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb7fb7000
fstat64(3, {st_mode=S_IFREG|0755, st_size=11910834, ...}) = 0
mmap2(NULL, 1234036, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0xb7e89000
mmap2(0xb7fb3000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x129) = 0xb7fb3000
mmap2(0xb7fb6000, 1140, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fb6000
close(3)= 0
open("/usr/lib/libXtst.so.6", O_RDONLY) = 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\16\0\0004\0\0\0"..., 512) 
= 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=19308, ...}) = 0
mmap2(NULL, 22096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0xb7e83000
mmap2(0xb7e88000, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4) = 0xb7e88000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340k\1\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1795760, ...}) = 0
mmap2(NULL, 1505576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0xb7d13000
mmap2(0xb7e7d000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16a) = 0xb7e7d000
mmap2(0xb7e8, 10536, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7e8
close(3)= 0
open("/usr/lib/libXext.so.6", O_RDONLY) = 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200'\0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=64492, ...}) = 0
mmap2(NULL, 63488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0xb7d03000
mmap2(0xb7d12000, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb7d12000
close(3)= 0
open("/usr/lib/libxcb.so.1", O_RDONLY)  = 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0pn\0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=112676, ...}) = 0
mmap2(NULL, 111376, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0xb7ce7000
mmap2(0xb7d02000, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b) = 0xb7d02000
close(3)= 0
open("/lib/libdl.so.2", O_RDONLY)   = 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\n\0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=18572, ...}) = 0
mmap2(NULL, 16500, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0xb7ce2000
mmap2(0xb7ce5000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7ce5000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb7ce1000
open("/usr/lib/libXau.so.6", O_RDONLY)  = 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\t\0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=8176, ...}) = 0
mmap2(NULL, 10992, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0xb7cde000
mmap2(0xb7ce, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7ce
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb7cdd000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7cdd6c0, 
limit:1048575, seg_32bit:1, contents:0, read_exec_only

Re: Xorg crashes...

[Ryan Daly]

On 01/06/2010 09:39 PM, Justin P. Mattock wrote:
>  you need a newer version of xmacros
> (everything is at cgit.freedesktop.org)

Got'em and installed in /usr/local.

> hopefully ubuntu is up-to-date
> i.g. hopefully it doesn't take
> much to use the latest version.
> (you can also grab the tar ball
> there if it becomes too much, or try older
> versions of ubuntu's package);
> 
> hard part right I see is pinpointing what exactly
> is exiting your server, so you don't have to
> do the trial and error approach.

I got a clean compile after using the latest version of the macros.

I compiled on a separate x86 system, but the same version of Ubuntu. 
Can I take xf86-input-evdev/src/.libs/evdev_drv.so and simply copy that 
to /usr/lib/xorg/modules/input/evdev_drv.so (the Ubuntu location) on the 
troubled system and restart X?  Should I continue to run w/ GDB attached 
to obtain another backtrace?


This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information.  If you are not the
intended recipient, notify the sender immediately and delete
this message.  Publication, reproduction, forwarding, or 
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392

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

Re: pointer acceleration property rename and docs

[Peter Hutterer]

On Wed, Jan 06, 2010 at 08:27:34PM +0100, Simon Thum wrote:
> Those patches should address the issues. The rename is skipped for now.

Please remember to add your signed-off-by to the patches.
(git commit -s does it automatically)


> From: Simon Thum 
> Date: Wed, 6 Jan 2010 19:43:59 +0100
> Subject: [PATCH 3/5] xfree86: document pointer acceleration in xorg.conf.man
> 
> ---
[...]
> +times slower. Use this for very accurate hit-the-pixel work.
> +.TP 7
> +.BI "Option \*qAccelerationScheme\*q  \*q" string \*q
> +Selects the scheme, which is the underlying algorithm.
> +.PP
> +.RS 7
> +.nf
> +.B  "predictable   default algorithm (behaving more predictable)"
> +.B  "lightweight   old acceleration code (as specified in the XInput spec)"

s/XInput/X protocol/

I've merged the patches locally with the above substitution. Please send me
the Signed-off-by and I'll include it in the next pull request.

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

Re: Xorg crashes...

[Justin P. Mattock]

On 01/06/10 18:21, Ryan Daly wrote:
> On 01/06/2010 03:59 PM, Justin P. Mattock wrote:
>> over here my xorg modules live in:
>> /usr/lib/xorg/modules/*
>> ubuntu might be the same(but can't remember).
>>
>> as for uninstalling, synaptic I think
>> might let you uninstall a module
>> individually, but you never know might
>> want to uninstall a whole mess load of stuff.
>> (dependencies)
>>
>> depending on what synaptic does if it wants to uninstall
>> a mess load, I would not even bother, and just locate
>> the evdev_drv.so/la modules rename them or move them to a
>> safe location. then git clone
>> git://anongit.freedesktop.org/xorg/driver/xf86-input-evdev
>> (or just leave them their and write over them with a fresh copy,
>> and when done use apt-get reinstall on it to copy that version again).
>>
>> compile it, remember you might need to specify the location of
>> the modules with a switch i.g.
>> ./configure --someswitch=/specifying/the/location/of/input/modules
>> (that's if ubuntu has them in another location other than default);
>>
>> then see if it fixes your issue.
>> now keep in mind it could be evdev, it could
>> even be libpthread or libxrandr.. tough to say.
>
> I grabbed the source and some dependencies, but I'm getting an error on
> the version of the macros installed.
>
> d...@riddler<31#>  sh autogen.sh
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal
> configure.ac:36: error: must install xorg-macros 1.3 or later before

  you need a newer version of xmacros
(everything is at cgit.freedesktop.org)

> running autoconf/autogen
> configure.ac:36: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
> aclocal: autom4te failed with exit status: 1
> autoreconf: aclocal failed with exit status: 1
>
> I'm not sure how to overcome that one...  Ubuntu provides a package that
> contains xorg-macros.m4, but I'm gathering that the version I have is
> too low.  I commented out the line that checks for the version to get
> passed it, but I'm not certain if that was OK.  I'm getting another
> error on the compilation:
>
> d...@riddler<36#>  make
> make  all-recursive
> make[1]: Entering directory `/home/daly/xf86-input-evdev'
> Making all in src
> make[2]: Entering directory `/home/daly/xf86-input-evdev/src'
> /bin/bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
> -I.. -I../include/   -I/usr/include/xorg -I/usr/include/pixman-1   -g
> -O2 -MT evdev.lo -MD -MP -MF .deps/evdev.Tpo -c -o evdev.lo evdev.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include/
> -I/usr/include/xorg -I/usr/include/pixman-1 -g -O2 -MT evdev.lo -MD -MP
> -MF .deps/evdev.Tpo -c evdev.c  -fPIC -DPIC -o .libs/evdev.o
> evdev.c: In function `EvdevKbdCtrl':
> evdev.c:1083: warning: ignoring return value of `write', declared with
> attribute warn_unused_result
> evdev.c: At top level:
> evdev.c:2097: error: `PACKAGE_VERSION_MAJOR' undeclared here (not in a
> function)
> evdev.c:2097: error: `PACKAGE_VERSION_MINOR' undeclared here (not in a
> function)
> evdev.c:2097: error: `PACKAGE_VERSION_PATCHLEVEL' undeclared here (not
> in a function)
> make[2]: *** [evdev.lo] Error 1
> make[2]: Leaving directory `/home/daly/xf86-input-evdev/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/daly/xf86-input-evdev'
> make: *** [all] Error 2
>
> Is that error caused by the macros being too old, or is that something
> completely unrelated?
>
>
hopefully ubuntu is up-to-date
i.g. hopefully it doesn't take
much to use the latest version.
(you can also grab the tar ball
there if it becomes too much, or try older
versions of ubuntu's package);

hard part right I see is pinpointing what exactly
is exiting your server, so you don't have to
do the trial and error approach.


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

Re: Xorg crashes...

[Ryan Daly]

On 01/06/2010 08:47 PM, Peter Hutterer wrote:
>> Right, but it's nothing I'm doing.  That's the problem.  I'm not 
>> initiating an exit, nor am I hitting ctrl-backspace (I don't think 
>> that's enabled by default any longer anyway).
>>
>> I'm looking for suggestions as to WHAT may be causing the SIGTERM.
> 
> either your session is terminating for some reason or another or you might
> be getting an unresolved symbol error. that terminates the server as well.
> try starting the server from a TTY instead of through gdm, once it exits you
> can see if it complains about a symbol error.

I'll definitely try this...but wouldn't any symbol errors appear in the 
gdb output that I captured?



This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information.  If you are not the
intended recipient, notify the sender immediately and delete
this message.  Publication, reproduction, forwarding, or 
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392

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

Re: Xorg crashes...

[Ryan Daly]

On 01/06/2010 03:59 PM, Justin P. Mattock wrote:
> over here my xorg modules live in:
> /usr/lib/xorg/modules/*
> ubuntu might be the same(but can't remember).
> 
> as for uninstalling, synaptic I think
> might let you uninstall a module
> individually, but you never know might
> want to uninstall a whole mess load of stuff.
> (dependencies)
> 
> depending on what synaptic does if it wants to uninstall
> a mess load, I would not even bother, and just locate
> the evdev_drv.so/la modules rename them or move them to a
> safe location. then git clone 
> git://anongit.freedesktop.org/xorg/driver/xf86-input-evdev
> (or just leave them their and write over them with a fresh copy,
> and when done use apt-get reinstall on it to copy that version again).
> 
> compile it, remember you might need to specify the location of
> the modules with a switch i.g.
> ./configure --someswitch=/specifying/the/location/of/input/modules
> (that's if ubuntu has them in another location other than default);
> 
> then see if it fixes your issue.
> now keep in mind it could be evdev, it could
> even be libpthread or libxrandr.. tough to say.

I grabbed the source and some dependencies, but I'm getting an error on 
the version of the macros installed.

d...@riddler <31#> sh autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
configure.ac:36: error: must install xorg-macros 1.3 or later before 
running autoconf/autogen
configure.ac:36: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

I'm not sure how to overcome that one...  Ubuntu provides a package that 
contains xorg-macros.m4, but I'm gathering that the version I have is 
too low.  I commented out the line that checks for the version to get 
passed it, but I'm not certain if that was OK.  I'm getting another 
error on the compilation:

d...@riddler <36#> make
make  all-recursive
make[1]: Entering directory `/home/daly/xf86-input-evdev'
Making all in src
make[2]: Entering directory `/home/daly/xf86-input-evdev/src'
/bin/bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I.. -I../include/   -I/usr/include/xorg -I/usr/include/pixman-1   -g 
-O2 -MT evdev.lo -MD -MP -MF .deps/evdev.Tpo -c -o evdev.lo evdev.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include/ 
-I/usr/include/xorg -I/usr/include/pixman-1 -g -O2 -MT evdev.lo -MD -MP 
-MF .deps/evdev.Tpo -c evdev.c  -fPIC -DPIC -o .libs/evdev.o
evdev.c: In function `EvdevKbdCtrl':
evdev.c:1083: warning: ignoring return value of `write', declared with 
attribute warn_unused_result
evdev.c: At top level:
evdev.c:2097: error: `PACKAGE_VERSION_MAJOR' undeclared here (not in a 
function)
evdev.c:2097: error: `PACKAGE_VERSION_MINOR' undeclared here (not in a 
function)
evdev.c:2097: error: `PACKAGE_VERSION_PATCHLEVEL' undeclared here (not 
in a function)
make[2]: *** [evdev.lo] Error 1
make[2]: Leaving directory `/home/daly/xf86-input-evdev/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/daly/xf86-input-evdev'
make: *** [all] Error 2

Is that error caused by the macros being too old, or is that something 
completely unrelated?


This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information.  If you are not the
intended recipient, notify the sender immediately and delete
this message.  Publication, reproduction, forwarding, or 
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392

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

Re: Xorg crashes...

[Peter Hutterer]

On Wed, Jan 06, 2010 at 08:26:40PM -0500, Ryan Daly wrote:
> On 01/06/2010 08:04 PM, Peter Hutterer wrote:
> >> The backtrace is pretty consistent with the following few lines:
> >>
> >> Program received signal SIGTERM, Terminated.
> >> 0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
> >> (gdb) backtrace r full
> >> #0  0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
> >> No symbol table info available.
> >> #1  0x7f1466f61516 in ?? () from 
> >> /usr/lib/xorg/modules/input//evdev_drv.so
> >> No symbol table info available.
> >> #2  0x00447723 in DisableDevice (dev=0x18a33a0) at 
> >> ../../dix/devices.c:407
> >>
> >> Are those lines pointing to a device or to the card possibly?
> >>
> >> I'm running the same version of Ubuntu on three different machines, and 
> >> I'm only experiencing the Xorg restarts on one system.  I'm at a loss...
> > 
> > 
> > uhm. SIGTERM is the termination signal. Something's shutting down your
> > server.
> 
> Right, but it's nothing I'm doing.  That's the problem.  I'm not 
> initiating an exit, nor am I hitting ctrl-backspace (I don't think 
> that's enabled by default any longer anyway).
> 
> I'm looking for suggestions as to WHAT may be causing the SIGTERM.

either your session is terminating for some reason or another or you might
be getting an unresolved symbol error. that terminates the server as well.
try starting the server from a TTY instead of through gdm, once it exits you
can see if it complains about a symbol error.

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

Re: Xorg crashes...

[Ryan Daly]

On 01/06/2010 08:04 PM, Peter Hutterer wrote:
>> The backtrace is pretty consistent with the following few lines:
>>
>> Program received signal SIGTERM, Terminated.
>> 0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
>> (gdb) backtrace r full
>> #0  0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
>> No symbol table info available.
>> #1  0x7f1466f61516 in ?? () from 
>> /usr/lib/xorg/modules/input//evdev_drv.so
>> No symbol table info available.
>> #2  0x00447723 in DisableDevice (dev=0x18a33a0) at 
>> ../../dix/devices.c:407
>>
>> Are those lines pointing to a device or to the card possibly?
>>
>> I'm running the same version of Ubuntu on three different machines, and 
>> I'm only experiencing the Xorg restarts on one system.  I'm at a loss...
> 
> 
> uhm. SIGTERM is the termination signal. Something's shutting down your
> server.

Right, but it's nothing I'm doing.  That's the problem.  I'm not 
initiating an exit, nor am I hitting ctrl-backspace (I don't think 
that's enabled by default any longer anyway).

I'm looking for suggestions as to WHAT may be causing the SIGTERM.
--


This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information.  If you are not the
intended recipient, notify the sender immediately and delete
this message.  Publication, reproduction, forwarding, or 
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392

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

Re: Xorg crashes...

[Peter Hutterer]

On Wed, Jan 06, 2010 at 11:56:28AM -0500, Ryan Daly wrote:
> On 01/06/2010 10:53 AM, Jeremy Huddleston wrote:
> > On Jan 6, 2010, at 10:50, Ryan Daly wrote:
> > 
> >>> not sure whats going on, but by
> >>> looking at the log I see some userspace tools
> >>> erroring out(which should not keep the screen from
> >>> going forward), but I also see something about
> >>> fglrx not found.. could either mean that you
> >>> haven't the xorg module, as well as the kernel module,
> >>> or the fglrx module is crapping out with the
> >>> xserver version(had this a while ago with fglrx,
> >>> ended up switching to radeon);
> >>>
> >>> hope this helps.
> >>>
> >>> Justin P. Mattock
> >>>
> >> Justin - thanks for your reply.
> >>
> >> Is fglrx ATI specific?  I have a nVidia card.  I'm not sure how they all 
> >> play together, though.
> > 
> > fglrx is the closed-source ATI driver
> > 
> 
> OK.  That rules that out then...
> 
> The backtrace is pretty consistent with the following few lines:
> 
> Program received signal SIGTERM, Terminated.
> 0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
> (gdb) backtrace r full
> #0  0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
> No symbol table info available.
> #1  0x7f1466f61516 in ?? () from 
> /usr/lib/xorg/modules/input//evdev_drv.so
> No symbol table info available.
> #2  0x00447723 in DisableDevice (dev=0x18a33a0) at 
> ../../dix/devices.c:407
> 
> Are those lines pointing to a device or to the card possibly?
> 
> I'm running the same version of Ubuntu on three different machines, and 
> I'm only experiencing the Xorg restarts on one system.  I'm at a loss...


uhm. SIGTERM is the termination signal. Something's shutting down your
server.

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

ANN: xterm patch #254

[Thomas Dickey]

 Patch #254 - 2010/1/6

 * add  a  configure-check to eliminate install-ti rule from Makefile
   when  the system has no tic (terminfo compiler) program. This lets
   one use the install-full rule more consistently.
 * amend  change  to  WriteText() function in [258]patch #252 to take
   into  account  the  colorAttrMode  resource  (report  by Krzysztof
   Kotlenga).
 * document titleModes resource in manpage, added in [259]patch #252.
 * modify tcap-query table entries for shifted up/down cursor keys to
   match ncurses convention.
 * improve  lookup  of  termcap-query  data,  allowing  for duplicate
   keycodes versus missing entries.
 * add control sequence which can be used to modify the terminal data
   used for the termcap-keyboard.
 * improve   portability   of   tcap-query  feature,  using  terminfo
   functions in preference to termcap on systems having terminfo.
 * improve font-setting/querying control (OSC 50):
  + when TrueType font is selected, the TrueType faceName will be
set, rather than the bitmap font.
  + when  TrueType font is selected, querying returns the name of
the TrueType font.
  + querying  a font recognizes the relative-font convention that
setting a font could use.
 * add menu-entry for allowColorOps.
 * add  new  resources  for  fine-tuning menu entries: allowColorOps,
   disallowedColorOps, disallowedFontOps and disallowedTcapOps.
 * correct logic for disabling the "TrueType Fonts" menu item; it was
   not ensuring that the faceName resource value was non-empty.
 * implement VT520-style controls DECSMBV and DECSWBV for setting the
   margin- and warning-bell volume.
 * fix  a  minor  error from [260]patch #243 which made the zIconBeep
   feature use a minor-error tone rather than an informational tone.
 * add a null-pointer check for the case where renderFont resource is
   true,  but  faceName  resource  is  unset,  used in logic to strip
   "xft:"  prefix  from  [261]patch  #251  changes  (patch by Michael
   Riepe).
 * add  special  case  to  configure  CF_XOPEN_SOURCE  macro  to  use
   extensions on Darwin (patch by Dennis Preiser).
 * improve  configure  checks  for  regular  expressions  header  and
   library
 * update config.guess, config.sub

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpctzOBmKm4o.pgp
Description: PGP signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

some help please X freeze laptop

[Morgan M.C.M-L]

Hello

I've been installing
NetBSD on a laptop Acer Inspire 1350 but I have some trooble with X.

1- 'X -configure' gave me a skeleton in '/root/xorg.conf.new'

2- I wrote in :

HorizSync31.5 - 48.0
VertRefresh  59.0 - 75.0
Modes "1024x768"

3- 'X -config /root/xorg.conf.new' gave me red/black vertical waves and 
the lappy was frozen.


4- Changing driver 'Via' by 'Vesa' gave me red/black/blue vertical waves 
and the lappy was frozen.


5- Trying lots of diferents 'Modes' and 'Refresh' have been the same.

6- xorgconfig gave me a file wich freeze with a black screen.



So I think I will  ?? Compile a new Xorg ?? Xfree ?? At least I need 
little help. Here are some files 'Xorg.0.log, xorg.conf, 
xorg.conf.xorgconfig, dmesg'



X.Org X Server 1.4.2
Release Date: 11 June 2008
X Protocol Version 11, Revision 0
Build Operating System: NetBSD/i386  - 
Current Operating System: NetBSD delphine-2. 5.0.1 NetBSD 5.0.1 (GENERIC) #0: 
Thu Jul 30 01:39:11 UTC 2009  
bui...@b8.netbsd.org:/home/builds/ab/netbsd-5-0-1-RELEASE/i386/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/i386/compile/GENERIC
 i386
Build Date: 11 June 2008  04:31:59PM
 
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: Tue Jan  5 23:12:25 2010
(++) Using config file: "xorg.conf.new"
(==) ServerLayout "X.org Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor0"
(**) |   |-->Device "Card0"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) `fonts.dir' not found (or not valid) in "/usr/X11R7/lib/X11/fonts/Speedo/".
Entry deleted from font path.
(Run 'mkfontdir' on "/usr/X11R7/lib/X11/fonts/Speedo/").
(WW) `fonts.dir' not found (or not valid) in "/usr/X11R7/lib/X11/fonts/CID/".
Entry deleted from font path.
(Run 'mkfontdir' on "/usr/X11R7/lib/X11/fonts/CID/").
(==) Including the default font path 
/usr/X11R7/lib/X11/fonts/misc/,/usr/X11R7/lib/X11/fonts/TTF/,/usr/X11R7/lib/X11/fonts/Speedo/,/usr/X11R7/lib/X11/fonts/Type1/,/usr/X11R7/lib/X11/fonts/CID/,/usr/X11R7/lib/X11/fonts/75dpi/,/usr/X11R7/lib/X11/fonts/100dpi/.
(**) FontPath set to:
/usr/X11R7/lib/X11/fonts/misc/,
/usr/X11R7/lib/X11/fonts/TTF/,
/usr/X11R7/lib/X11/fonts/Type1/,
/usr/X11R7/lib/X11/fonts/75dpi/,
/usr/X11R7/lib/X11/fonts/100dpi/,
/usr/X11R7/lib/X11/fonts/misc/,
/usr/X11R7/lib/X11/fonts/TTF/,
/usr/X11R7/lib/X11/fonts/Speedo/,
/usr/X11R7/lib/X11/fonts/Type1/,
/usr/X11R7/lib/X11/fonts/CID/,
/usr/X11R7/lib/X11/fonts/75dpi/,
/usr/X11R7/lib/X11/fonts/100dpi/
(**) RgbPath set to "/usr/X11R7/lib/X11/rgb"
(**) ModulePath set to "/usr/X11R7/lib/modules"
(II) Loader magic: 0x81b8a60
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.3
X.Org Video Driver: 2.0
X.Org XInput driver : 2.0
X.Org Server Extension : 0.3
X.Org Font Renderer : 0.5
(II) Loader running on netbsd
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R7/lib/modules//libpcidata.so
(II) Module pcidata: vendor="X.Org Foundation"
compiled for 1.4.2, module version = 1.0.0
ABI class: X.Org Video Driver, version 2.0
(--) Using wscons driver in pcvt compatibility mode (version 3.32)
(--) using VT number 5

(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000
(WW) OS did not count PCI devices, guessing wildly
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1106,3205 card 1106,7205 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 1106,b168 card , rev 00 class 06,04,00 hdr 01
(II) PCI: 00:07:0: chip 104c,ac50 card fffc, rev 02 class 06,07,00 hdr 02
(II) PCI: 00:08:0: chip 104c,8026 card 1025,0033 rev 00 class 0c,00,10 hdr 00
(II) PCI: 00:10:0: chip 1106,3038 card 1025,0033 rev 80 class 0c,03,00 hdr 80
(II) PCI: 00:10:1: chip 1106,3038 card 1025,0033 rev 80 class 0c,03,00 hdr 80
(II) PCI: 00:10:2: chip 1106,3038 card 1025,0033 rev 80 class 0c,03,00 hdr 80
(II) PCI: 00:10:3: chip 1106,3104 card 1025,0033 rev 82 class 0c,03,20 hdr 00
(II) PCI: 00:11:0: chip 1106,3177 card 1025,0033 rev 00 class 06,01,00 hdr 80
(II) PCI: 00:11:1: chip 1106,0571 card 1025,0033 rev 06 class 01,01,8a hdr 00
(II) PCI: 00:11:5: chip 1106,3059 card 1025,0033 rev 50 class 04,01,00 hdr 00
(II) PCI: 00:11:6: chip 1106,3068 card 1025,0033 rev 80 class 07,80,00 hdr 00
(II) PCI: 00:12:0: chip 1106,3065 card 1025,0033 rev 74 class 02,00,00 hdr 00
(II) PCI: 01:00:0: chip 1106,7205 card 1025,0033 rev 01 class 03,00,00 

Re: Xorg crashes...

[Justin P. Mattock]

On 01/06/10 11:54, Ryan Daly wrote:
> On 01/06/2010 02:28 PM, Justin P. Mattock wrote:
>>
>> alright.. so at least you can switch
>> modules i.g. from nvidia to vesa and such.
>>   From what it seems your hitting something
>> maybe with evdev, or mouse/kbd(but could be wrong).
>>
>> over here I've noticed something like that
>> with using fluxbox and the latest xserver from git.
>> every so often if I right click
>> the xserver will exit out instantly.
>>
>> hmm.. from your log I see something
>> with evdev, maybe you should upgrade
>> the evdev module(from git) to see if this problem
>> has been fixed for you.
>
> I'm running the stock Xorg from Ubuntu 9.10.  They're using version
> 2:1.6.4-2ubuntu4, but /usr/lib/xorg/modules/input/evdev_drv.so lives in
> another package (xserver-xorg-input-evdev) which is version
> 1:2.2.5-1ubuntu6.
>
> Would I be able to insert an updated module without changing anything else?
> --
>
>


over here my xorg modules live in:
/usr/lib/xorg/modules/*
ubuntu might be the same(but can't remember).

as for uninstalling, synaptic I think
might let you uninstall a module
individually, but you never know might
want to uninstall a whole mess load of stuff.
(dependencies)

depending on what synaptic does if it wants to uninstall
a mess load, I would not even bother, and just locate
the evdev_drv.so/la modules rename them or move them to a
safe location. then git clone 
git://anongit.freedesktop.org/xorg/driver/xf86-input-evdev
(or just leave them their and write over them with a fresh copy,
and when done use apt-get reinstall on it to copy that version again).

compile it, remember you might need to specify the location of
the modules with a switch i.g.
./configure --someswitch=/specifying/the/location/of/input/modules
(that's if ubuntu has them in another location other than default);

then see if it fixes your issue.
now keep in mind it could be evdev, it could
even be libpthread or libxrandr.. tough to say.



Justin P. Mattock

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

Re: Xorg Crashes ... Ryan Daly

[Ryan Daly]

On 01/06/2010 02:49 PM, Tim McConnell wrote:
> 
> Thanks,
> Tim McConnell
> mailto:timothy.mcconn...@comcast.net>>
> 
> 
> 
> On Wed, 2010-01-06 at 11:27 -0800, xorg-requ...@lists.freedesktop.org wrote:
> 
> What is the model of the Nvidia card? Also what do you have installed as 
> far as software versions (xorg, that sort of thing)?
> I know in Fedora there are different versions of the Nvidia drivers that 
> you have to get from a separate repo ( I think Debian calls them non 
> free contribs, wouldn't know about any version of Unbuntu), to me it 
> sounds like you have the wrong drivers installed. 
> 

The model of the card is below:
: linux13 63#; lspci | fgrep -i nvidi
02:00.0 VGA compatible controller: nVidia Corporation G84 [Quadro FX 
570] (rev a1)


I have the most recent Xorg packages provided by Ubuntu.  The Xorg 
server is below:


: linux13 72#; apt-cache show xserver-xorg-core
Package: xserver-xorg-core
Priority: optional
Section: x11
Installed-Size: 4264
Maintainer: Ubuntu X-SWAT 
Original-Maintainer: Debian X Strike Force 
Architecture: i386
Source: xorg-server
Version: 2:1.6.4-2ubuntu4
[...]


I also have the most recent proprietary nVidia driver provided by Ubuntu:
ii  nvidia-185-kernel-source 185.18.36-0ubuntu9 
 NVIDIA binary kernel module source
--


This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information.  If you are not the
intended recipient, notify the sender immediately and delete
this message.  Publication, reproduction, forwarding, or 
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392

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

Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.10.0

[Tino Keitel]

Hi,

I built the release version against mesa 7.7 rc2, drm 2.4.16, kernel
2.6.33-rc2. Window movement is still very slow with composite enabled
on i945.

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

Re: troobleshoot X on laptop

[Morgan M.C.M-L]

>>
>>  
>> 
>>
>> Sujet:
>> troobleshoot X on laptop
>> Expéditeur:
>> "Morgan M.C.M-L" 
>> Date:
>> Wed, 06 Jan 2010 19:17:08 +0100
>> Destinataire:
>> xorg@lists.freedesktop.org
>>
>> Destinataire:
>> xorg@lists.freedesktop.org
>>
>>
>> Hello
>>
>> I've been installing
>> NetBSD on a laptop Acer Inspire 1350 but I have some trooble with X.
>>
>> 1- 'X -configure' gave me a skeleton in '/root/xorg.conf.new'
>>
>> 2- I wrote in :
>>
>> HorizSync31.5 - 48.0
>> VertRefresh  59.0 - 75.0
>> Modes "1024x768"
>>
>> 3- 'X -config /root/xorg.conf.new' gave me red/black vertical waves 
>> and the lappy was frozen.
>>
>> 4- Changing driver 'Via' by 'Vesa' gave me red/black/blue vertical 
>> waves and the lappy was frozen.
>>
>> 5- Trying lots of diferents 'Modes' and 'Refresh' have been the same.
>>
>> 6- xorgconfig gave me a file wich freeze with a black screen.
>>
>>
>>
>> So I think I will  ?? Compile a new Xorg ?? Xfree ?? At least I need 
>> little help. Here are some files 'Xorg.0.log, xorg.conf, 
>> xorg.conf.xorgconfig, dmesg'
>>
>> 
>>
>> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 
>> 2005,
>> 2006, 2007, 2008, 2009
>> The NetBSD Foundation, Inc.  All rights reserved.
>> Copyright (c) 1982, 1986, 1989, 1991, 1993
>> The Regents of the University of California.  All rights reserved.
>>
>> NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 01:39:11 UTC 2009
>> 
>> bui...@b8.netbsd.org:/home/builds/ab/netbsd-5-0-1-RELEASE/i386/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/i386/compile/GENERIC
>>  
>>
>> total memory = 702 MB
>> avail memory = 678 MB
>> timecounter: Timecounters tick every 10.000 msec
>> timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
>> Acer,Inc. Aspire 1350 (3A24)
>> mainbus0 (root)
>> cpu0 at mainbus0: AMD 686-class, 796MHz, id 0x6a0
>> cpu0: AMD Powernow! K7 Technology 1716 MHz
>> cpu0: frequencies available (Mhz): 1188 1320 1452 1584 1716
>> acpi0 at mainbus0: Intel ACPICA 20080321
>> acpi0: X/RSDT: OemId , AslId < LTP,>
>> LNKA: ACPI: Found matching pin for 0.16.INTA at func 0: 0
>> LNKB: ACPI: Found matching pin for 0.16.INTB at func 1: 0
>> LNKC: ACPI: Found matching pin for 0.16.INTC at func 2: 0
>> LNKD: ACPI: Found matching pin for 0.16.INTD at func 3: 0
>> LNKA: ACPI: Found matching pin for 0.17.INTA at func 1: 0
>> LNKC: ACPI: Found matching pin for 0.17.INTC at func 5: 9
>> LNKA: ACPI: Found matching pin for 0.18.INTA at func 0: 4
>> LNKB: ACPI: Found matching pin for 0.7.INTA at func 0: 255
>> LNKB: ACPI: Found matching pin for 0.8.INTA at func 0: 5
>> acpi0: SCI interrupting at int 10
>> acpi0: fixed-feature power button present
>> timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000
>> ACPI-Fast 24-bit timer
>> acpiacad0 at acpi0 (ACAD, ACPI0003): ACPI AC Adapter
>> acpibat0 at acpi0 (BAT1, PNP0C0A-1): ACPI Battery (Control Method)
>> npx1 at acpi0 (COPR, PNP0C04)
>> npx1: io 0xf0-0xff irq 13
>> npx1: reported by CPUID; using exception 16
>> attimer1 at acpi0 (TMR, PNP0100): AT Timer
>> attimer1: io 0x40-0x43 irq 0
>> pcppi1 at acpi0 (SPKR, PNP0800)
>> pcppi1: io 0x61
>> midi0 at pcppi1: PC speaker (CPU-intensive output)
>> sysbeep0 at pcppi1
>> pckbc1 at acpi0 (KBC0, PNP0303): kbd port
>> pckbc1: io 0x60,0x64 irq 1
>> pckbc2 at acpi0 (MSE0, PNP0F13): aux port
>> pckbc2: irq 12
>> LPTB (PNP0400) at acpi0 not configured
>> FDC (PNP0700) at acpi0 not configured
>> FIR (NSC6001) at acpi0 not configured
>> acpiec0 at acpi0 (EC0, PNP0C09): ACPI Embedded Controller
>> acpiec0: io 0x62,0x66
>> acpibut0 at acpi0 (PWRB, PNP0C0C): ACPI Power Button
>> acpibut1 at acpi0 (SLPB, PNP0C0E): ACPI Sleep Button
>> acpilid0 at acpi0 (LID, PNP0C0D): ACPI Lid Switch
>> acpitz0 at acpi0 (THRM): critical 87.0C passive 52.0C, passive cooling
>> apm0 at acpi0: Power Management spec V1.2
>> attimer1: attached to pcppi1
>> pckbd0 at pckbc1 (kbd slot)
>> pckbc1: using irq 1 for kbd slot
>> wskbd0 at pckbd0: console keyboard
>> pms0 at pckbc1 (aux slot)
>> pms0: Synaptics touchpad version 5.8
>> pms0: Up/down buttons, Palm detect, Multi-finger
>> pckbc1: using irq 12 for aux slot
>> wsmouse0 at pms0 mux 0
>> pci0 at mainbus0 bus 0: configuration mode 1
>> pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
>> pchb0 at pci0 dev 0 function 0
>> pchb0: vendor 0x1106 product 0x3205 (rev. 0x00)
>> agp0 at pchb0 (v3): aperture at 0xe000, size 0x1000
>> ppb0 at pci0 dev 1 function 0: vendor 0x1106 product 0xb168 (rev. 0x00)
>> pci1 at ppb0 bus 1
>> pci1: i/o space, memory space enabled
>> vga1 at pci1 dev 0 function 0: vendor 0x1106 product 0x7205 (rev. 0x01)
>> wsdisplay0 at vga1 kbdmux 1: console (80x25, vt100 emulation), using 
>> wskbd0
>> wsmux1: connecting to wsdisplay0
>> drm at vga1 not configured
>> cbb0 at pci0 dev 7 function 0: vendor 0x104

Re: Xorg Crashes ... Ryan Daly

[Tim McConnell]

Thanks, 
Tim McConnell



On Wed, 2010-01-06 at 11:27 -0800, xorg-requ...@lists.freedesktop.org
wrote:

What is the model of the Nvidia card? Also what do you have installed as
far as software versions (xorg, that sort of thing)?
I know in Fedora there are different versions of the Nvidia drivers that
you have to get from a separate repo ( I think Debian calls them non
free contribs, wouldn't know about any version of Unbuntu), to me it
sounds like you have the wrong drivers installed.  


> 
> Message: 3
> Date: Wed, 06 Jan 2010 10:31:14 -0800
> From: "Justin P. Mattock" 
> Subject: Re: Xorg crashes...
> To: Ryan Daly 
> Cc: xorg@lists.freedesktop.org
> Message-ID: <4b44d6f2.2040...@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 01/06/10 08:56, Ryan Daly wrote:
> > On 01/06/2010 10:53 AM, Jeremy Huddleston wrote:
> >> On Jan 6, 2010, at 10:50, Ryan Daly wrote:
> >>
>  not sure whats going on, but by
>  looking at the log I see some userspace tools
>  erroring out(which should not keep the screen from
>  going forward), but I also see something about
>  fglrx not found.. could either mean that you
>  haven't the xorg module, as well as the kernel module,
>  or the fglrx module is crapping out with the
>  xserver version(had this a while ago with fglrx,
>  ended up switching to radeon);
> 
>  hope this helps.
> 
>  Justin P. Mattock
> 
> >>> Justin - thanks for your reply.
> >>>
> >>> Is fglrx ATI specific?  I have a nVidia card.  I'm not sure how they all
> >>> play together, though.
> >>
> >> fglrx is the closed-source ATI driver
> >>
> >
> > OK.  That rules that out then...
> >
> > The backtrace is pretty consistent with the following few lines:
> >
> > Program received signal SIGTERM, Terminated.
> > 0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
> > (gdb) backtrace r full
> > #0  0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
> > No symbol table info available.
> > #1  0x7f1466f61516 in ?? () from
> > /usr/lib/xorg/modules/input//evdev_drv.so
> > No symbol table info available.
> > #2  0x00447723 in DisableDevice (dev=0x18a33a0) at
> > ../../dix/devices.c:407
> >
> > Are those lines pointing to a device or to the card possibly?
> >
> > I'm running the same version of Ubuntu on three different machines, and
> > I'm only experiencing the Xorg restarts on one system.  I'm at a loss...
> >
> 
> yeah.. fglrx is specific to
> ati chipsets(but could be wrong).
> 
> In your case If you have nvidia
> you probably should be using
> nv, nouveau, or the proprietary module.
> 
> if you can does changing your xorg.conf
> to use vesa/vga have the xserver start properly?
> 
> 
> Justin P. Mattock
> 
> 
> 
> --
> 
> Message: 4
> Date: Wed, 06 Jan 2010 13:47:14 -0500
> From: Ryan Daly 
> Subject: Re: Xorg crashes...
> To: "Justin P. Mattock" 
> Cc: xorg@lists.freedesktop.org
> Message-ID: <4b44dab2.3090...@ctc.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On 01/06/2010 01:31 PM, Justin P. Mattock wrote:
> >>> fglrx is the closed-source ATI driver
> >>>
> >>
> >> OK.  That rules that out then...
> >>
> >> The backtrace is pretty consistent with the following few lines:
> >>
> >> Program received signal SIGTERM, Terminated.
> >> 0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
> >> (gdb) backtrace r full
> >> #0  0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
> >> No symbol table info available.
> >> #1  0x7f1466f61516 in ?? () from
> >> /usr/lib/xorg/modules/input//evdev_drv.so
> >> No symbol table info available.
> >> #2  0x00447723 in DisableDevice (dev=0x18a33a0) at
> >> ../../dix/devices.c:407
> >>
> >> Are those lines pointing to a device or to the card possibly?
> >>
> >> I'm running the same version of Ubuntu on three different machines, and
> >> I'm only experiencing the Xorg restarts on one system.  I'm at a loss...
> >>
> > 
> > yeah.. fglrx is specific to
> > ati chipsets(but could be wrong).
> > 
> > In your case If you have nvidia
> > you probably should be using
> > nv, nouveau, or the proprietary module.
> > 
> > if you can does changing your xorg.conf
> > to use vesa/vga have the xserver start properly?
> 
> Well, my xorg.conf is set up to use the nVidia proprietary module:
> 
> Section "Device"
>  Identifier "Device0"
>  Driver "nvidia"
>  VendorName "NVIDIA Corporation"
>  BoardName  "Quadro FX 570"
> EndSection
> 
> The X server will start properly and it allows me to log in.  Sometimes 
> my session will last hours, other times it will restart 3 or 4 times in 
> 15 minutes.  I have left it logged in without it restarting on its own, 
> so it definitely appears to be triggered by something.  I can say this, 
> I'm typing 100% of the time it ups and restarts on me.
> 
> I have left the proprietary driver out and still received a restart

Re: Xorg crashes...

[Ryan Daly]

On 01/06/2010 02:28 PM, Justin P. Mattock wrote:
> 
> alright.. so at least you can switch
> modules i.g. from nvidia to vesa and such.
>  From what it seems your hitting something
> maybe with evdev, or mouse/kbd(but could be wrong).
> 
> over here I've noticed something like that
> with using fluxbox and the latest xserver from git.
> every so often if I right click
> the xserver will exit out instantly.
> 
> hmm.. from your log I see something
> with evdev, maybe you should upgrade
> the evdev module(from git) to see if this problem
> has been fixed for you.

I'm running the stock Xorg from Ubuntu 9.10.  They're using version 
2:1.6.4-2ubuntu4, but /usr/lib/xorg/modules/input/evdev_drv.so lives in 
another package (xserver-xorg-input-evdev) which is version 
1:2.2.5-1ubuntu6.

Would I be able to insert an updated module without changing anything else?
--


This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information.  If you are not the
intended recipient, notify the sender immediately and delete
this message.  Publication, reproduction, forwarding, or 
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392

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

Re: Xorg crashes...

[Justin P. Mattock]

On 01/06/10 10:47, Ryan Daly wrote:
> On 01/06/2010 01:31 PM, Justin P. Mattock wrote:
 fglrx is the closed-source ATI driver

>>>
>>> OK.  That rules that out then...
>>>
>>> The backtrace is pretty consistent with the following few lines:
>>>
>>> Program received signal SIGTERM, Terminated.
>>> 0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
>>> (gdb) backtrace r full
>>> #0  0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
>>> No symbol table info available.
>>> #1  0x7f1466f61516 in ?? () from
>>> /usr/lib/xorg/modules/input//evdev_drv.so
>>> No symbol table info available.
>>> #2  0x00447723 in DisableDevice (dev=0x18a33a0) at
>>> ../../dix/devices.c:407
>>>
>>> Are those lines pointing to a device or to the card possibly?
>>>
>>> I'm running the same version of Ubuntu on three different machines, and
>>> I'm only experiencing the Xorg restarts on one system.  I'm at a loss...
>>>
>>
>> yeah.. fglrx is specific to
>> ati chipsets(but could be wrong).
>>
>> In your case If you have nvidia
>> you probably should be using
>> nv, nouveau, or the proprietary module.
>>
>> if you can does changing your xorg.conf
>> to use vesa/vga have the xserver start properly?
>
> Well, my xorg.conf is set up to use the nVidia proprietary module:
>
> Section "Device"
>   Identifier "Device0"
>   Driver "nvidia"
>   VendorName "NVIDIA Corporation"
>   BoardName  "Quadro FX 570"
> EndSection
>
> The X server will start properly and it allows me to log in.  Sometimes
> my session will last hours, other times it will restart 3 or 4 times in
> 15 minutes.  I have left it logged in without it restarting on its own,
> so it definitely appears to be triggered by something.  I can say this,
> I'm typing 100% of the time it ups and restarts on me.
>
> I have left the proprietary driver out and still received a restart, too.
>
>

alright.. so at least you can switch
modules i.g. from nvidia to vesa and such.
 From what it seems your hitting something
maybe with evdev, or mouse/kbd(but could be wrong).

over here I've noticed something like that
with using fluxbox and the latest xserver from git.
every so often if I right click
the xserver will exit out instantly.

hmm.. from your log I see something
with evdev, maybe you should upgrade
the evdev module(from git) to see if this problem
has been fixed for you.


Justin P. Mattock


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

Re: pointer acceleration property rename and docs

[Simon Thum]

Those patches should address the issues. The rename is skipped for now.


Peter Hutterer wrote:
> thanks, that woke me up. I was struggling this morning :)
> 
> On Tue, Jan 05, 2010 at 09:13:47PM +0100, Simon Thum wrote:
>> another round of ptr accel patches. I didn't send to the dev list to
>> maybe gather more input on the rename.
>>
>> First, I renamed 'constant deceleration' to 'downscaling', and adjusted
>> the property and option names. I hope that it is a good name; I'm still
>> open for suggestions. Many suggested 'sensitivity' but I think that
>> isn't it.
>>
>> Only the option rename is backwards-compatible though, to avoid
>> redundant input properties. Peter, is that one OK with you?
> 
> I don't think this is necessary. We're nitpicking on the wording here and
> given the number of languages out there there's always going to be some
> ambiguity. with this patch you're breaking user configurations for very
> little benefit - especially since the same could be achieved by having
> more verbose documentation.
> 
>> Next, I added the possibility to change pointer feedback controls
>> through options. The InputClass stuff makes it more sensible to do this.
>> TBH, I never figured why it was limited to command line options.
> 
> there's protocol requests to adjust this at runtime and those are the only
> pointer-acceleration related ones supported in GUI configuration tools
> today. so arguably it's not essential since we've gone for years without it.
> also, aren't you trying to get people off the old scheme? not having config
> options is one way to do it :)
> 
> see for more comments in-line though.
>  
>> Third, some whitespace style fixes. Nothing functional.
> 
> meh, as usual with whitespace patches. since you're the one working most of
> that code - if you're happy with that go for it.
> 
>> Last but not least, the documentation should now reflect reality wrt
>> pointer acceleration. Affects the xorg.conf.man and --help output.
>>
>> It's perfectly possible the man changes are bogus, I just copied around
>> and I seem not to have broken things.
> 
>> From da0b0bb6bda12eaa7f3cece3ab72056e73afa765 Mon Sep 17 00:00:00 2001
>> From: Simon Thum 
>> Date: Tue, 5 Jan 2010 14:46:35 +0100
>> Subject: [PATCH 2/4] xfree86: set accelaration controls from options
>>
>> Since config backends become better integrated, we may as well
>> cover all the acceleration-related settings. Previously, the only
>> way to set acceleration controls (aka pointer feedback) upfront
>> was command-line options to the Xorg binary.
>> ---
>>  hw/xfree86/common/xf86Xinput.c |   33 +++--
>>  1 files changed, 31 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
>> index 979b265..90ed1bc 100644
>> --- a/hw/xfree86/common/xf86Xinput.c
>> +++ b/hw/xfree86/common/xf86Xinput.c
>> @@ -199,12 +199,12 @@ ProcessVelocityConfiguration(DeviceIntPtr pDev, char* 
>> devname, pointer list,
>>  
>>  static void
>>  ApplyAccelerationSettings(DeviceIntPtr dev){
>> -int scheme;
>> +int scheme, i;
>>  DeviceVelocityPtr pVel;
>>  LocalDevicePtr local = (LocalDevicePtr)dev->public.devicePrivate;
>>  char* schemeStr;
>>  
>> -if(dev->valuator){
>> +if(dev->valuator && dev->ptrfeed){
> 
> this whitespace should be fixed as part of this patch.
> 
>>  schemeStr = xf86SetStrOption(local->options, "AccelerationScheme", "");
>>  
>>  scheme = dev->valuator->accelScheme.number;
>> @@ -247,6 +247,35 @@ ApplyAccelerationSettings(DeviceIntPtr dev){
>>pVel);
>>  break;
>>  }
>> +
>> +/*
>> + * process acceleration controls (or 'pointer feedback') as device
>> + * options, to allow people to set acceleration preferences more
>> + * flexibly than command-line trickery.
>> + */
> 
> I don't think this comment is necessary since the stuff below is pretty
> standard code.
> 
>> +i = xf86SetIntOption(local->options, "AccelerationNumerator",
>> + dev->ptrfeed->ctrl.num);
>> +if (i >= 0)
>> +dev->ptrfeed->ctrl.num = i;
>> +
>> +i = xf86SetIntOption(local->options, "AccelerationDenominator",
>> + dev->ptrfeed->ctrl.den);
>> +if (i > 0)
>> +dev->ptrfeed->ctrl.den = i;
>> +
>> +i = xf86SetIntOption(local->options, "AccelerationThreshold",
>> + dev->ptrfeed->ctrl.threshold);
>> +if (i >= 0)
>> +dev->ptrfeed->ctrl.threshold = i;
>> +
>> +/* mostly a no-op anyway */
>> +(*dev->ptrfeed->CtrlProc)(dev, &dev->ptrfeed->ctrl);
>> +
>> +xf86Msg(X_CONFIG, "%s: (accel) acceleration factor: %.3f\n",
>> +local->name, ((float)dev->ptrfeed->ctrl.num)/
>> + ((float)dev->ptrfeed->ctrl.den));
>> +  

Re: Xorg crashes...

[Ryan Daly]

On 01/06/2010 01:31 PM, Justin P. Mattock wrote:
>>> fglrx is the closed-source ATI driver
>>>
>>
>> OK.  That rules that out then...
>>
>> The backtrace is pretty consistent with the following few lines:
>>
>> Program received signal SIGTERM, Terminated.
>> 0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
>> (gdb) backtrace r full
>> #0  0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
>> No symbol table info available.
>> #1  0x7f1466f61516 in ?? () from
>> /usr/lib/xorg/modules/input//evdev_drv.so
>> No symbol table info available.
>> #2  0x00447723 in DisableDevice (dev=0x18a33a0) at
>> ../../dix/devices.c:407
>>
>> Are those lines pointing to a device or to the card possibly?
>>
>> I'm running the same version of Ubuntu on three different machines, and
>> I'm only experiencing the Xorg restarts on one system.  I'm at a loss...
>>
> 
> yeah.. fglrx is specific to
> ati chipsets(but could be wrong).
> 
> In your case If you have nvidia
> you probably should be using
> nv, nouveau, or the proprietary module.
> 
> if you can does changing your xorg.conf
> to use vesa/vga have the xserver start properly?

Well, my xorg.conf is set up to use the nVidia proprietary module:

Section "Device"
 Identifier "Device0"
 Driver "nvidia"
 VendorName "NVIDIA Corporation"
 BoardName  "Quadro FX 570"
EndSection

The X server will start properly and it allows me to log in.  Sometimes 
my session will last hours, other times it will restart 3 or 4 times in 
15 minutes.  I have left it logged in without it restarting on its own, 
so it definitely appears to be triggered by something.  I can say this, 
I'm typing 100% of the time it ups and restarts on me.

I have left the proprietary driver out and still received a restart, too.


This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information.  If you are not the
intended recipient, notify the sender immediately and delete
this message.  Publication, reproduction, forwarding, or 
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392

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

Re: Xorg crashes...

[Justin P. Mattock]

On 01/06/10 08:56, Ryan Daly wrote:
> On 01/06/2010 10:53 AM, Jeremy Huddleston wrote:
>> On Jan 6, 2010, at 10:50, Ryan Daly wrote:
>>
 not sure whats going on, but by
 looking at the log I see some userspace tools
 erroring out(which should not keep the screen from
 going forward), but I also see something about
 fglrx not found.. could either mean that you
 haven't the xorg module, as well as the kernel module,
 or the fglrx module is crapping out with the
 xserver version(had this a while ago with fglrx,
 ended up switching to radeon);

 hope this helps.

 Justin P. Mattock

>>> Justin - thanks for your reply.
>>>
>>> Is fglrx ATI specific?  I have a nVidia card.  I'm not sure how they all
>>> play together, though.
>>
>> fglrx is the closed-source ATI driver
>>
>
> OK.  That rules that out then...
>
> The backtrace is pretty consistent with the following few lines:
>
> Program received signal SIGTERM, Terminated.
> 0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
> (gdb) backtrace r full
> #0  0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
> No symbol table info available.
> #1  0x7f1466f61516 in ?? () from
> /usr/lib/xorg/modules/input//evdev_drv.so
> No symbol table info available.
> #2  0x00447723 in DisableDevice (dev=0x18a33a0) at
> ../../dix/devices.c:407
>
> Are those lines pointing to a device or to the card possibly?
>
> I'm running the same version of Ubuntu on three different machines, and
> I'm only experiencing the Xorg restarts on one system.  I'm at a loss...
>

yeah.. fglrx is specific to
ati chipsets(but could be wrong).

In your case If you have nvidia
you probably should be using
nv, nouveau, or the proprietary module.

if you can does changing your xorg.conf
to use vesa/vga have the xserver start properly?


Justin P. Mattock

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

Re: small EDID library (possible start)

[Kai-Uwe Behrmann]

Am 06.01.10, 10:38 -0500 schrieb Adam Jackson:
> On Wed, 2010-01-06 at 11:13 +0100, Kai-Uwe Behrmann wrote:

>> Soren Sandmann is mentioned as the author of edid-parse.c (2007). I took

Ah

> edid-parse.c is part of libgnome-desktop.  It's not used in the server
> at all.

>> The attached oyranos_edid_parse code is my try on a API. It provides a
>> very simple interface. EDID is passed as a void* pointer. Results are
>> returned in a flat structure array. The results are a kind of key value
>> pairs. The core API consists of only three functions. The returned values
>> are referenced by a key name.
>> Additionally a XEdid_s structure is declared only for further parsing
>> convinience. The parsed items are merely colorimetric and identification
>> parts. Missed is the timing and the resolution stuff, which can be added
>> later.
>
> I'd actually started down these lines shortly after this year's XDC in
> Portland, so, thank you for reminding me!  The EDID interpretation code
> in the server is one of the last remaining targets for things to strip
> out of the server and reuse elsewhere, so I started hacking up a library
> that would be plausibly good enough to be used from both X and
> libgnome-desktop.  Currently it looks like this:
>
> http://cgit.freedesktop.org/~ajax/libminitru/

... currently the monitor modes parsing.

> As far as API design goes, X's internal API is pretty entirely wrong.  I
> don't see any value in storing any unpacked representation of the EDID
> block internally to the library, it's just wasted memory given how
> trivial it is to unpack on the fly.  You also really really need to

The key/value API fits relatively well the Oyranos data handling model. So 
that shurely lead me in the first place. Oyranos is designed towards 
being as generic as possible and as specific as needed.

But as it is Xorg code I have no deeper opinion and can follow your 
design.

> parse extension blocks, and you need to be able to handle display
> information data that isn't EDID.

agreed

> So I think the API we want is less about querying for specific fields of
> the EDID, but about asking questions and getting answers (which may be
> "I don't know, the device doesn't specify").  X wants to ask questions
> like "what is the list of supported modes" and "would this mode work if
> I tried it".  I imagine Oyranos wants to ask questions like "what's the
> white point" and "what's the gamma curve look like".

As long as the answers do not change between releases, thats all fine.
... and EDID is still available as a last means.

> Your XEDID API doesn't do this.  It hands back a list of key/values, but
> then the application still has to know how to interpret them; _each_
> application has to know how to interpret them.

The keys/values are used currently to generate ICC profiles for monitors 
and to identify the monitor devices. So at least for Oyranos that kind of 
works and as far as I can see, there is not much further code needed.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

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

Re: Xorg crashes...

[Ryan Daly]

On 01/06/2010 10:53 AM, Jeremy Huddleston wrote:
> On Jan 6, 2010, at 10:50, Ryan Daly wrote:
> 
>>> not sure whats going on, but by
>>> looking at the log I see some userspace tools
>>> erroring out(which should not keep the screen from
>>> going forward), but I also see something about
>>> fglrx not found.. could either mean that you
>>> haven't the xorg module, as well as the kernel module,
>>> or the fglrx module is crapping out with the
>>> xserver version(had this a while ago with fglrx,
>>> ended up switching to radeon);
>>>
>>> hope this helps.
>>>
>>> Justin P. Mattock
>>>
>> Justin - thanks for your reply.
>>
>> Is fglrx ATI specific?  I have a nVidia card.  I'm not sure how they all 
>> play together, though.
> 
> fglrx is the closed-source ATI driver
> 

OK.  That rules that out then...

The backtrace is pretty consistent with the following few lines:

Program received signal SIGTERM, Terminated.
0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
(gdb) backtrace r full
#0  0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0
No symbol table info available.
#1  0x7f1466f61516 in ?? () from 
/usr/lib/xorg/modules/input//evdev_drv.so
No symbol table info available.
#2  0x00447723 in DisableDevice (dev=0x18a33a0) at 
../../dix/devices.c:407

Are those lines pointing to a device or to the card possibly?

I'm running the same version of Ubuntu on three different machines, and 
I'm only experiencing the Xorg restarts on one system.  I'm at a loss...


This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information.  If you are not the
intended recipient, notify the sender immediately and delete
this message.  Publication, reproduction, forwarding, or 
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392

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

Re: Xorg crashes...

[Jeremy Huddleston]

On Jan 6, 2010, at 10:50, Ryan Daly wrote:

>> not sure whats going on, but by
>> looking at the log I see some userspace tools
>> erroring out(which should not keep the screen from
>> going forward), but I also see something about
>> fglrx not found.. could either mean that you
>> haven't the xorg module, as well as the kernel module,
>> or the fglrx module is crapping out with the
>> xserver version(had this a while ago with fglrx,
>> ended up switching to radeon);
>> 
>> hope this helps.
>> 
>> Justin P. Mattock
>> 
> 
> Justin - thanks for your reply.
> 
> Is fglrx ATI specific?  I have a nVidia card.  I'm not sure how they all 
> play together, though.

fglrx is the closed-source ATI driver



smime.p7s
Description: S/MIME cryptographic signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg crashes...

[Ryan Daly]

> not sure whats going on, but by
> looking at the log I see some userspace tools
> erroring out(which should not keep the screen from
> going forward), but I also see something about
> fglrx not found.. could either mean that you
> haven't the xorg module, as well as the kernel module,
> or the fglrx module is crapping out with the
> xserver version(had this a while ago with fglrx,
> ended up switching to radeon);
> 
> hope this helps.
> 
> Justin P. Mattock
> 

Justin - thanks for your reply.

Is fglrx ATI specific?  I have a nVidia card.  I'm not sure how they all 
play together, though.
--


This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information.  If you are not the
intended recipient, notify the sender immediately and delete
this message.  Publication, reproduction, forwarding, or 
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392

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

Re: small EDID library (possible start)

[Adam Jackson]

On Wed, 2010-01-06 at 11:13 +0100, Kai-Uwe Behrmann wrote:

> That is Adam Jackson's parse-edid.c with lots of global variables and no 
> library interface at all (2009). That is fine for the intented usage as 
> command line tool, but unfortunedly not a comfortable base for a library.

Yeah, that's really intended to be a conformance tester, not a general
purpose tool.

> Soren Sandmann is mentioned as the author of edid-parse.c (2007). I took 
> some pices from that. I like the returned structure at a first glace very 
> much. Unfortunedly the returned structure is quite static. So I was 
> unshure whether this will be extensible as library. I think this code is 
> used internally of Xorg for EDID parsing. The API appears to be visible 
> only to the server and is not exported. Please correct me if I am wrong.

edid-parse.c is part of libgnome-desktop.  It's not used in the server
at all.

> The attached oyranos_edid_parse code is my try on a API. It provides a 
> very simple interface. EDID is passed as a void* pointer. Results are 
> returned in a flat structure array. The results are a kind of key value 
> pairs. The core API consists of only three functions. The returned values 
> are referenced by a key name.
> Additionally a XEdid_s structure is declared only for further parsing 
> convinience. The parsed items are merely colorimetric and identification 
> parts. Missed is the timing and the resolution stuff, which can be added 
> later.

I'd actually started down these lines shortly after this year's XDC in
Portland, so, thank you for reminding me!  The EDID interpretation code
in the server is one of the last remaining targets for things to strip
out of the server and reuse elsewhere, so I started hacking up a library
that would be plausibly good enough to be used from both X and
libgnome-desktop.  Currently it looks like this:

http://cgit.freedesktop.org/~ajax/libminitru/

As far as API design goes, X's internal API is pretty entirely wrong.  I
don't see any value in storing any unpacked representation of the EDID
block internally to the library, it's just wasted memory given how
trivial it is to unpack on the fly.  You also really really need to
parse extension blocks, and you need to be able to handle display
information data that isn't EDID.

So I think the API we want is less about querying for specific fields of
the EDID, but about asking questions and getting answers (which may be
"I don't know, the device doesn't specify").  X wants to ask questions
like "what is the list of supported modes" and "would this mode work if
I tried it".  I imagine Oyranos wants to ask questions like "what's the
white point" and "what's the gamma curve look like".

Your XEDID API doesn't do this.  It hands back a list of key/values, but
then the application still has to know how to interpret them; _each_
application has to know how to interpret them.

- 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: small EDID library (possible start)

[Éric Piel]

Op 06-01-10 11:13, Kai-Uwe Behrmann schreef:
> I found several issues with existing EDID parsing code for usage as
> library in Oyranos (a colour management system).
> To move on with a EDID parsing API, I attach a Oyranos header file for
> the EDID parsing.
> The EDID API is selfcontained and a bit tweaked toward Xorg integration.
> But beside that code may look like Xorg to me, core developers might
> find several issues. I would like to adress issues as long I get aware
> of them.
> 
> 
> Why a new attempt? There preexists several code since long time to parse
> EDIDs data blocks.
> 
> That is Adam Jackson's parse-edid.c with lots of global variables and no
> library interface at all (2009). That is fine for the intented usage as
> command line tool, but unfortunedly not a comfortable base for a library.
> 
> Soren Sandmann is mentioned as the author of edid-parse.c (2007). I took
> some pices from that. I like the returned structure at a first glace
> very much. Unfortunedly the returned structure is quite static. So I was
> unshure whether this will be extensible as library. I think this code is
> used internally of Xorg for EDID parsing. The API appears to be visible
> only to the server and is not exported. Please correct me if I am wrong.
> 
> 
> The attached oyranos_edid_parse code is my try on a API. It provides a
> very simple interface. EDID is passed as a void* pointer. Results are
> returned in a flat structure array. The results are a kind of key value
> pairs. The core API consists of only three functions. The returned
> values are referenced by a key name.
> Additionally a XEdid_s structure is declared only for further parsing
> convinience. The parsed items are merely colorimetric and identification
> parts. Missed is the timing and the resolution stuff, which can be added
> later.
> 
Hello,
This is just to let you know that Anssi Hannulla is currently working on
an EDID parser (in C) for Mandriva, and it seems pretty advanced. So you
might want to get some inspiration from it as well:

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/monitor-edid/current/SOURCES/monitor-edid-3.0.tar.bz2?view=log

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

small EDID library (possible start)

[Kai-Uwe Behrmann]

I found several issues with existing EDID parsing code for usage as 
library in Oyranos (a colour management system).
To move on with a EDID parsing API, I attach a Oyranos header file 
for the EDID parsing.

The EDID API is selfcontained and a bit tweaked toward Xorg integration.
But beside that code may look like Xorg to me, core developers might find 
several issues. I would like to adress issues as long I get aware of them.



Why a new attempt? There preexists several code since long time to parse 
EDIDs data blocks.


That is Adam Jackson's parse-edid.c with lots of global variables and no 
library interface at all (2009). That is fine for the intented usage as 
command line tool, but unfortunedly not a comfortable base for a library.


Soren Sandmann is mentioned as the author of edid-parse.c (2007). I took 
some pices from that. I like the returned structure at a first glace very 
much. Unfortunedly the returned structure is quite static. So I was 
unshure whether this will be extensible as library. I think this code is 
used internally of Xorg for EDID parsing. The API appears to be visible 
only to the server and is not exported. Please correct me if I am wrong.



The attached oyranos_edid_parse code is my try on a API. It provides a 
very simple interface. EDID is passed as a void* pointer. Results are 
returned in a flat structure array. The results are a kind of key value 
pairs. The core API consists of only three functions. The returned values 
are referenced by a key name.
Additionally a XEdid_s structure is declared only for further parsing 
convinience. The parsed items are merely colorimetric and identification 
parts. Missed is the timing and the resolution stuff, which can be added 
later.


Comments are welcome.


kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org/** @file oyranos_edid_parse.h
 *
 *  Oyranos is an open source Colour Management System 
 *
 *  @par Copyright:
 *2005-2009 (C) Kai-Uwe Behrmann
 *
 *  @briefEDID data block parsing
 *  @internal
 *  @author   Kai-Uwe Behrmann 
 *  @par License:
 *MIT 
 *  @since2005/01/31
 */

#ifndef OYRANOS_EDID_PARSE_H
#define OYRANOS_EDID_PARSE_H
#include  /* size_t */

/** @brief \internal DDC struct */
typedef struct {
  unsigned char sig[8];
  unsigned char mnft_id[2];/* [8] manufaturer ID */
  unsigned char model_id[2];   /* [10] model ID */
  unsigned char ser_id[2]; /* [12] serial ID */
  unsigned char dummy_li[2];
  unsigned char week;  /* [16] Week */
  unsigned char year;  /* [17] + 1990 => Year */
  unsigned char major_version; /* [18] */
  unsigned char minor_version; /* [19] */
  unsigned char video_input_type;  /* [20] */
  unsigned char width; /* [21] */
  unsigned char height;/* [22] */
  unsigned char gamma_factor;  /* [23] */
  unsigned char dpms;  /* [24] */
  unsigned char rg;/* [25] colour information */
  unsigned char wb;/* [26] */
  unsigned char rY;/* [27] */
  unsigned char rX;/* [28] */
  unsigned char gY;/* [29] */
  unsigned char gX;/* [30] */
  unsigned char bY;/* [31] */
  unsigned char bX;/* [32] */
  unsigned char wY;/* [33] */
  unsigned char wX;/* [34] */
  unsigned char etiming1;  /* [35] */
  unsigned char etiming2;  /* [36] */
  unsigned char mtiming;   /* [37] */
  unsigned char stdtiming[16]; /* [38] */
  unsigned char text1[18]; /* [54] Product string */
  unsigned char text2[18]; /* [72] text 2 */
  unsigned char text3[18]; /* [90] text 3 */
  unsigned char text4[18]; /* [108] text 4 */
  unsigned char extension_blocks;  /* [126] number of following extensions*/
  unsigned char checksum;  /* [127] */
} XEdid_s;

typedef enum {
  XEDID_OK,
  XEDID_WRONG_SIGNATURE
} XEDID_ERROR_e;

typedef enum {
  XEDID_VALUE_TEXT,
  XEDID_VALUE_INT,
  XEDID_VALUE_DOUBLE
} XEDID_VALUE_e;

union XEdidValue_u {
  char * text;
  double dbl;
  intinteger;
};

typedef struct {
  const char * key;
  XEDID_VALUE_etype;
  union XEdidValue_u   value;
} XEdidKeyValue_s;

/* basic access functions */
XEDID_ERROR_e  XEdidParse( void  * edid,
   XEdidKeyValue_s  ** list,
   int   * count );
XEDID_ERROR_e  XEdidFree ( XEdidKeyValue_s  ** list );
const char *   XEdidErrorToString( XEDID_ERROR_e   error );

/* convinience functions */
XEDID_ERROR_e  XEdidPrintString  ( void  * edid,

Re: Intel driver problem

[Dirk De Becker]

Stupid me! Apparently, I did not have anything in /root/.xinitrc. 
Adding 
exec /usr/bin/startlxde 
makes the X server start just fine.

Thanks for the help, 
Dirk

Dirk De Becker wrote:

  
Apparently, if I start xdm instead of running startx, it works OK. I
will now try to find out why startx fails.
Thanks for your help, 
  
Dirk
  
Julien Cristau wrote:
  
On Tue, Jan  5, 2010 at 10:09:47 +0100, Dirk De Becker wrote:

[...]
  

  (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "us"
(II) Dell Dell USB Keyboard: Close
(II) UnloadModule: "evdev"
(II) HID 04d9:1400: Close
(II) UnloadModule: "evdev"
(II) HID 04d9:1400: Close
(II) UnloadModule: "evdev"
(II) Power Button: Close
(II) UnloadModule: "evdev"
(II) Power Button: Close
(II) UnloadModule: "evdev"



This log looks like X starts up fine, and then the session ends.  Are
you sure it's not your session crashing or terminating prematurely,
rather than an X problem?

Cheers,
Julien
___
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




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

Re: pointer acceleration property rename and docs

[Simon Thum]

Peter Hutterer wrote:
> thanks, that woke me up. I was struggling this morning :)
always a pleasure.

> I don't think this is necessary. We're nitpicking on the wording here and
> given the number of languages out there there's always going to be some
> ambiguity. with this patch you're breaking user configurations for very
> little benefit - especially since the same could be achieved by having
> more verbose documentation.
Yes and - eh. I've got the gut feeling the term 'constant deceleration'
is actually incorrect. But I'll postpone until I'm sure about that.

>> Next, I added the possibility to change pointer feedback controls
>> through options. The InputClass stuff makes it more sensible to do this.
>> TBH, I never figured why it was limited to command line options.
> 
> there's protocol requests to adjust this at runtime and those are the only
> pointer-acceleration related ones supported in GUI configuration tools
> today. so arguably it's not essential since we've gone for years without it.
> also, aren't you trying to get people off the old scheme? not having config
> options is one way to do it :)
Yes, but all the accel stuff is runtime and config and per-device,
except the ptr feedback settings. So this a) fills a gap and b) since
the InputClass stuff came live, it actually makes some sense.

I'd prefer my devices to work in the login manager just as in the
session, except if I explicitly change my session. Distros could
sensibly ship pre-tuned accel or no-accel fragments for greater DE
independence.

Runtime config is nice, but being able to leverage InputClass,
you're avoiding the ID/Name matching problems of today's xinput.

> 
> Reviewed-by: Peter Hutterer 
Thanks!

>> +is accelerated with respect to physical device motion. It also provides an
>> +option to scale down devices, which supersedes workarounds based on tweaking
>> +the acceleration controls. Most of these can be adjusted at runtime using 
>> the
>> +pointer feedback and input property mechanisms (see the xinput(1) man page).
>> +Note that desktop environments typically do this for at least the first 
>> three
>> +options (which correspond to pointer feedback settings). Only the most
>> +important acceleration options are discussed here.
> 
> I think the part form "It also" to "feeback settings)" can be cut out. It's
> quite verbose with little information that matters in a man page. Personal
> opinion here. the xinput reference should come after the options, IMO.
I wonder if the scaling workaround was officially blessed. If yes, I'd
rather keep that stuff.

>> +.BI "Option \*qAccelerationDenominator\*q  \*q" integer \*q
>> +Set the denominator of the acceleration factor.
> 
> what do the numerator and denominator mean though? Having the formula here
> would be nice.
I'll try to be more helpful here.

>> +.TP 7
>> +.BI "Option \*qAccelerationThreshold\*q  \*q" integer \*q
>> +Set the threshold, i.e. the velocity (device units/t) required for 
>> acceleration
>> +to kick in.
> 
> What's the unit of "t"?  
> How about something like this:
> "Set the threshold in device units/second at which acceleration takes effect.
> Device movements below the threshold are unaccelerated."
Sounds fine, except that t=10ms by default, and device units has
deceleration applied. Ah, and not every profile honors threshold as
described :) Thus I aimed for simplicity.

>> +.B  "predictable   default algorithm (behaving intuitively predictable)"
>> +.B  "lightweight   old acceleration code"
>> +.B  "none  no acceleration or deceleration"
>> +
> 
> biased, very biased :)
I did my best ;)
> IIRC, the old accel code is specified in the X Protocol, at least in parts.
> So rather than an "old severely constrained" algorithm point to the protocol
> specification and call your new one flexible instead of the old one
> constrained.
> 
> also, unless you've got a study to show it, I'm somewhat uncomfortable with
> "intuitively predictable".
If X.Org or redhat would be sponsoring it - no problem ;)
Anyway, I'll try to be more balanced. I admit "intuitively predictable"
is hard to show, but "more predictable" is surely achieved.

>> -ErrorF("-t #   mouse threshold (pixels)\n");
>> +ErrorF("-t #   default mouse threshold (pixels/t)\n");
> 
> separate patch for these two hunks. also - the protocol states that a value
> of -1 restores the default (ChangePointerControl, p72). does this mean it
> restores the default given here or some built-in default? if the latter,
> this patch is obsolete since -a and -t only set the startup values.
The former, actually. The defaults then propagate to new devices. Which
is especially nice since you can set invalid values here.

Anything uncommented is agreed to. I'll be sending an new version the
following days. Thanks for the review!

Cheers,

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