Re: Building X
Russell Shaw wrote: > Peter Hutterer wrote: >> On Fri, Sep 19, 2008 at 01:46:21PM +1000, Russell Shaw wrote: >>> I built X from git. I get a stippled background when X starts but the >>> mouse cursor is invisible. The mouse is working because i tested it >>> with xev. I built and installed in this order: >> commit e02f864fdf19a5ab1682336be343c57fdb69ef43 >> Author: Adam Jackson <[EMAIL PROTECTED]> >> Date: Wed Aug 20 13:24:03 2008 -0400 >> >> Suppress cursor display until the first XDefineCursor() request. >> >> Yes, this means the server will start without showing a cursor. Pretty >> much any application that wants to interact with the mouse will define >> cursors, so this essentially just delays showing it until gdm (or >> whatever) loads. > > Hi, > That's somewhat interesting. A lot of old or simple X programs (and X > tutorials) > didn't call XDefineCursor() from what i've seen. > > When i ran xev (from git), the cursor didn't appear either. I'm testing X on > a remote pc and so don't need xdm or any apps running on X. > > Any testing is simpler if the complications of xdm or a window manager > are avoided. > > I think it would be a good idea if there was a default cursor present if > nothing else. I realized that without a window manager you get an ugly black cross cursor which isn't real useful. X should've had a default arrow cursor. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
On Fri, 2008-09-19 at 15:02 +1000, Russell Shaw wrote: > I think it would be a good idea if there was a default cursor present if > nothing else. At least when using the ugly grey stipple. If you're using -br, the missing-cursor plan seems reasonable. Otherwise, it makes debugging X server startup a bit harder. -- [EMAIL PROTECTED] 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: [xorg-server-1.5.0] keyb hang after starting q3
On Thu, Sep 18, 2008 at 11:51:47PM -0500, Tobias Jakobi wrote: > After ioquake3 is started all keyb and mouse input stop. You can't move > the cursor, you can't click. Switching to another application isn't > possible, even switching to the VTs isn't possible. > All input is simply dead. > [...] > I consider this a serious bug with the X input. > [mi] EQ overflowing. The server is probably stuck in an infinite loop. > [mi] mieqEnequeue: out-of-order valuator event; dropping. > [mi] EQ overflowing. The server is probably stuck in an infinite loop. > [mi] mieqEnequeue: out-of-order valuator event; dropping. > [mi] EQ overflowing. The server is probably stuck in an infinite loop. > [mi] mieqEnequeue: out-of-order valuator event; dropping. I think your server is probably stuck in an infinite loop :) Input is still coming in, but not being processed because something else is hogging the server. > (EE) intel(0): underrun on pipe B! I blame the graphics driver. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
Peter Hutterer wrote: > On Fri, Sep 19, 2008 at 01:46:21PM +1000, Russell Shaw wrote: >> I built X from git. I get a stippled background when X starts but the >> mouse cursor is invisible. The mouse is working because i tested it >> with xev. I built and installed in this order: > > commit e02f864fdf19a5ab1682336be343c57fdb69ef43 > Author: Adam Jackson <[EMAIL PROTECTED]> > Date: Wed Aug 20 13:24:03 2008 -0400 > > Suppress cursor display until the first XDefineCursor() request. > > Yes, this means the server will start without showing a cursor. Pretty > much any application that wants to interact with the mouse will define > cursors, so this essentially just delays showing it until gdm (or > whatever) loads. Hi, That's somewhat interesting. A lot of old or simple X programs (and X tutorials) didn't call XDefineCursor() from what i've seen. When i ran xev (from git), the cursor didn't appear either. I'm testing X on a remote pc and so don't need xdm or any apps running on X. Any testing is simpler if the complications of xdm or a window manager are avoided. I think it would be a good idea if there was a default cursor present if nothing else. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
On Fri, Sep 19, 2008 at 01:46:21PM +1000, Russell Shaw wrote: > I built X from git. I get a stippled background when X starts but the > mouse cursor is invisible. The mouse is working because i tested it > with xev. I built and installed in this order: commit e02f864fdf19a5ab1682336be343c57fdb69ef43 Author: Adam Jackson <[EMAIL PROTECTED]> Date: Wed Aug 20 13:24:03 2008 -0400 Suppress cursor display until the first XDefineCursor() request. Yes, this means the server will start without showing a cursor. Pretty much any application that wants to interact with the mouse will define cursors, so this essentially just delays showing it until gdm (or whatever) loads. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Fix for damage protocol specification
Here's a tiny fix for the damage protocol specification 0001-Document-that-parts-may-be-None-for-DamageSubtract.patch Description: application/mbox ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Building X
Hi, I built X from git. I get a stippled background when X starts but the mouse cursor is invisible. The mouse is working because i tested it with xev. I built and installed in this order: macros scrnsaverproto randrproto renderproto fixesproto damageproto xcmiscproto xextproto xproto scrnsaverproto bigreqsproto resourceproto fontsproto inputproto kbproto videoproto compositeproto resourceproto xineramaproto evieproto cursors bitmaps libxtrans libXext libXinerama libxkbfile libfontenc libXfont libXau libXdmcp Xfixes Xcomposite libpciaccess xkbcomp xcursorgen mkfontscale mkfontdir bdftopcf xkeyboard-config util cursor-misc misc-misc bitstream-100dpi bitstream-75dpi bitstream-speedo alias pixman hal xserver (with --disable-config-hal --disable-aiglx --disable-glx --disable-dri --disable-dri2) xf86-video-radeonhd xf86-input-keyboard xf86-input-mouse x-input-evdev _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/beta: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.5.99.1 Release Date: (unreleased) X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.24-acer i686 Current Operating System: Linux beta 2.6.24-acer #6 PREEMPT Thu Aug 14 22:12:43 EST 2008 i686 Build Date: 07 September 2008 06:55:49PM 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: "/usr/local/var/log/Xorg.0.log", Time: Fri Sep 19 13:42:20 2008 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Generic Monitor" (**) | |-->Device "Card0" (**) |-->Input Device "Generic Keyboard" (**) |-->Input Device "Configured Mouse" (**) Option "AllowMouseOpenFail" "false" (==) Automatically adding devices (==) Automatically enabling devices (==) Including the default font path built-ins. (**) FontPath set to: /usr/local/lib/X11/fonts/misc, /usr/local/lib/X11/fonts/100dpi, /usr/local/lib/X11/fonts/75dpi, built-ins (**) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x1aa0 (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:*([EMAIL PROTECTED]:0:0) ATI Technologies Inc RV530LE [Radeon X1600/X1650 PRO] rev 0, Mem @ 0xd000/268435456, 0xe900/65536, I/O @ 0xa000/256, BIOS @ 0x/131072 (--) PCI: ([EMAIL PROTECTED]:0:1) ATI Technologies Inc RV530LE [Radeon X1650 PRO] (Secondary) rev 0, Mem @ 0xe901/65536 (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 by default. (II) "dbe" will be loaded by default. (II) "glx" will be loaded by default. (II) "dri" will be loaded by default. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.5.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 /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.5.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 DOUBLE-BUFFER (II) LoadModule: "glx" (WW) Warning, couldn't open module glx (II) UnloadModule: "glx" (EE) Failed to load module "glx" (module does not exist, 0) (II) LoadModule: "dri" (WW) Warning, couldn't open module dri (II) UnloadModule: "dri" (EE) Failed to load module "dri" (module does not exist, 0) (II) LoadModule: "radeonhd" (II) Loading /usr/local/lib
Re: X crashes on switching to console - intel_bufmgr_fake.c:1302: intel_bufmgr_fake_evict_all: Assertion failed
On Fri, Sep 19, 2008 at 7:02 AM, Jeff Chua <[EMAIL PROTECTED]>
wrote:
> Swtiching to console resulted in X crashing. Same problem with trying
> to suspend to ram.
>
> X: intel_bufmgr_fake.c:1302: intel_bufmgr_fake_evict_all: Assertion
> `((&bufmgr_fake->fenced)->next == (&bufmgr_fake->fenced))' failed.
>
This turns out to be the drm module that's emitting this problem.
Taking out the assert() calls fixed the problem with switching to VT
consoles and suspending to ram.
I don't know what's the implication of taking away these two calls. Please
advise.
Thanks,
Jeff
--- /v6/src2/cvs/drm/drm/libdrm/intel/intel_bufmgr_fake.c 2008-09-12
20:02:27 +0800
+++ /v6/src2/drm/drm/libdrm/intel/intel_bufmgr_fake.c 2008-09-19 08:35:29
+0800
@@ -1296,12 +1296,6 @@
*/
dri_bufmgr_fake_wait_idle(bufmgr_fake);
- /* Check that we hadn't released the lock without having fenced the last
-* set of buffers.
-*/
- assert(DRMLISTEMPTY(&bufmgr_fake->fenced));
- assert(DRMLISTEMPTY(&bufmgr_fake->on_hardware));
-
DRMLISTFOREACHSAFE(block, tmp, &bufmgr_fake->lru) {
/* Releases the memory, and memcpys dirty contents out if necessary. */
free_block(bufmgr_fake, block);
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-input-evdev 2.0.5
Just one fix - some kernels invalidate the device late after resume, leaving us with dead devices. This issue is addressed by reopening the device if a read error occurs. Peter Hutterer (2): Attempt to re-open devices on read errors. evdev 2.0.5 git tag: xf86-input-evdev-2.0.5 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.5.tar.bz2 MD5: aabf047629d279b0eb4cd236b9de3121 xf86-input-evdev-2.0.5.tar.bz2 SHA1: 9b6b77e6d9aa9bfbe0b7a31d4d070c0f6d372311 xf86-input-evdev-2.0.5.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.5.tar.gz MD5: cdca14fa2fd7daffcb3c8d459e480b4c xf86-input-evdev-2.0.5.tar.gz SHA1: 801bb0c74803e61d65868fe61198840a2e1aa465 xf86-input-evdev-2.0.5.tar.gz signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver from git: libXi dependency
On Fri, Sep 19, 2008 at 04:28:20AM +0700, Mikhail Gusarov wrote: > Xi/chdevhier.h includes which is in libXi, but > xserver configure script does not check for the libXi. Is it a bug? Thanks, that's a bug. Fix pushed as cc20112a65d3f641ce0261c86a541f94fae5215c. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
XDMCP Docs...
Hi all, recently I was put in charge of creating a clean room implementation of the XDMCP protocol for our Apple Terminal Server product. This was done for various political and technical reasons which are beyond the scope of this email. I wanted to tell all of you that while I found the XDMCP.PS document helpful, I also found it lacking a little. So I started to document and create supplemental information for the XDMCP protocol and its current standards based implementation. You are welcome to reproduce and distribute the documents as a whole or in part as long as you give credit in your reproduced form to the company Aqua Connect and to me (Joseph Cohen). You can find these documents at:http://www.aquaconnect.net/?p=400 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
X crashes on switching to console - intel_bufmgr_fake.c:1302: intel_bufmgr_fake_evict_all: Assertion failed
Swtiching to console resulted in X crashing. Same problem with trying to suspend to ram. X: intel_bufmgr_fake.c:1302: intel_bufmgr_fake_evict_all: Assertion `((&bufmgr_fake->fenced)->next == (&bufmgr_fake->fenced))' failed. X.Org X Server 1.5.99.1 Release Date: (unreleased) X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.27-rc6 i686 (II) Loading extension DRI2 (II) LoadModule: "intel" (II) Loading /usr/X11/lib/xorg/modules/drivers//intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.5.99.1, module version = 2.5.96 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) intel(0): [XvMC] i915_xvmc driver initialized. (II) AIGLX: Screen 0 is not DRI2 capable (II) AIGLX: Loaded and initialized /usr/X11/lib/dri/i915_dri.so Reverting back to older drm, mesa and intel_drv make the problem go away. It seems the bufmgr_fake is causing this to fail, but there're too much depending on mesa, drm and intel_drv that I don't know how to bisect it. Thanks, Jeff. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver from git: libXi dependency
Twas brillig at 19:11:39 18.09.2008 UTC-03 when [EMAIL PROTECTED] did gyre and gimble: >> MG>> Xi/chdevhier.h includes which is in libXi, >> MG> Oh, I seem to have no clue here. It is in proto, >> After some head-scratching, I found that XInput.h was in proto, but in >> libXi now, so the question about the lack of check in configure is still >> valid. TV> From configure.ac: "XINPUT extension is integral part of the server" I don't ask whether the switch --disable-xinput should be added. -- pgpnYiT6nakMf.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver from git: libXi dependency
Mikhail Gusarov escreveu: > Twas brillig at 04:48:54 19.09.2008 UTC+07 when [EMAIL PROTECTED] did gyre > and gimble: > > MG>> Xi/chdevhier.h includes which is in libXi, > MG> Oh, I seem to have no clue here. It is in proto, > > After some head-scratching, I found that XInput.h was in proto, but in > libXi now, so the question about the lack of check in configure is still > valid. From configure.ac: "XINPUT extension is integral part of the server" 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: xserver from git: libXi dependency
Twas brillig at 04:48:54 19.09.2008 UTC+07 when [EMAIL PROTECTED] did gyre and gimble: MG>> Xi/chdevhier.h includes which is in libXi, MG> Oh, I seem to have no clue here. It is in proto, After some head-scratching, I found that XInput.h was in proto, but in libXi now, so the question about the lack of check in configure is still valid. -- pgphzuJ1fHbla.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver from git: libXi dependency
Twas brillig at 04:28:20 19.09.2008 UTC+07 when [EMAIL PROTECTED] did gyre and gimble: MG> Xi/chdevhier.h includes which is in libXi, Oh, I seem to have no clue here. It is in proto, -- pgpH0GN46p11l.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xserver from git: libXi dependency
Hi, Xi/chdevhier.h includes which is in libXi, but xserver configure script does not check for the libXi. Is it a bug? -- pgpJuxWIkZOIa.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
A couple of composite fixes from Owen Taylor
Owen Taylor has been poking at Composite for a while now and has helped uncover a couple of interesting corner cases. Here are two patches, the first is a correctness patch which fixes parent clip recomputation when windows move from automatic to manual redirection. The second is an optimization to eliminate descendent exposures on parent resize. -- [EMAIL PROTECTED] 0001-Switching-from-Automatic-to-Manual-redirect-needs-to.patch Description: application/mbox 0002-When-resizing-a-window-with-redirected-descendents.patch Description: application/mbox 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: Implementing RandR
On Thursday 18 September 2008 06:41:51 Jacob Welsh wrote: > > I'm currently working on implementing RandR support in the Xvnc server > > along with an extension protocol for the client to request that Xvnc > > changes its framebuffer size on demand. > > What version of RandR are you aiming to support? I don't know if you > know enough about X and VNC -- I certainly don't -- to implement RandR > 1.2 support, but that would be really nifty. I'm only working on having VNC sessions that can be resized for the moment. I don't know enough about RandR to implement anything else. Rotations are all hardcoded at the moment to use a 0 degree rotation (ie - normal) as we don't see much point in implementing rotations. Depth switching can already be done as part of the RFB protocol, so the only other thing in RandR that seems to make sense is multi-head support. > I'm imagining that multiple rfb clients connecting to a single Xvnc > could be registered as separate monitors, with their own modes as > determined by the client. Monitors and modes can be added and removed > dynamically via the existing XRandR 1.2 extension. And you could switch > between traditional "clone" mode and Xinerama-style with "xrandr" or a > 1.2-capable GUI. So basically you could turn two neighboring thin > clients into a "dual-head" setup effortlessly. Also it would presumably > solve your present mode weirdness problem. That sounds like an incredibly complex and insane project. I pity anyone who tries to implement that ;) > I'm sure that's a lot more work than you set out to do... and even RandR > 1.1 support in tightvnc will be much appreciated :) Thanks. I'm most of the way there now. The only problems I've got now are the one I detailed at the start of this thread, and that resizing to a desktop larger than the initial VNC desktop results in a segfault. I'm pretty sure it's because of a memory allocation problem (I don't think the framebuffer is reallocated when it's resized). Today I'm working on getting vncviewer's window to be resizable and to send a RFB request to the server to resize the framebuffer when it does so. I've implemented a new extension to the RFB protocol to allow the client to request desktop resizes. I hope to release my initial patches early next week, so I'll keep you in the loop if you want. Regards, George -- George Wright, http://www.gwright.org.uk 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: Notes on E-EDID and DisplayID support
On Wed, 2008-09-17 at 13:48 -0400, Adam Jackson wrote: > This will also get more complicated in the future. Apparently > constructing a conformant (hah!) EDID block was just too much work for > some vendors, so there's a new spec called DisplayID from VESA that > we'll have to deal with at some point. From what I've been able to > glean from the internet, it's a variable length format right from the > start, which means we probably won't be able to convert it to > cooked-EDID internally. I'd know more, but I don't have the spec yet, > as I don't have the site access password for VESA. I think Egbert does > though. > > For DisplayID I think we'd be better off with a new query API that keeps > the internal representation away from the drivers. I have the DID docs now! It looks very much like the CEA EDID extension, which really only reinforces my view that this needs to be API and not pile-of-structs. I think there's a straightforward way to programmatically detect DisplayID blocks as opposed to EDID, so I'll probably add at least hexdump for it to the DDC code. - 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: events in evdev.c
On Thu, 2008-09-18 at 09:24 -0700, Alan Coopersmith wrote: > Chuck Robey wrote: > > Sorry, I can't parse what you wrote. You don't know where I heard that > > Xorg is > > Linux-only? Is that what you said? My understanding *had been* that Xorg > > was > > trying to be compatible with as many Unixes as possible, and specifically > > avoid > > being Linux only, which is why seeing the depth of Linuxcode that is in your > > flagship input driver, evdev, surprised me so. I uderstood, from Peter's > > mail, > > that I'm wrong there, and the use of Linux-only ocde in that flagship > > driver was > > deliberate. Simply really surprised me, that's all. > > Xorg is not Linux-only, but evdev is. On Solaris & BSD, Xorg uses the > xf86-input-keyboard & xf86-input-mouse drivers instead. Both Solaris and BSD have very similar event APIs, afaik, and could easily have drivers for same. But they don't. Patches gratefully etc. - 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: events in evdev.c
Chuck Robey wrote: > Sorry, I can't parse what you wrote. You don't know where I heard that Xorg > is > Linux-only? Is that what you said? My understanding *had been* that Xorg was > trying to be compatible with as many Unixes as possible, and specifically > avoid > being Linux only, which is why seeing the depth of Linuxcode that is in your > flagship input driver, evdev, surprised me so. I uderstood, from Peter's > mail, > that I'm wrong there, and the use of Linux-only ocde in that flagship driver > was > deliberate. Simply really surprised me, that's all. Xorg is not Linux-only, but evdev is. On Solaris & BSD, Xorg uses the xf86-input-keyboard & xf86-input-mouse drivers instead. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: events in evdev.c
On Thu, Sep 18, 2008 at 9:10 AM, Chuck Robey <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Daniel Stone wrote: >> On Wed, Sep 17, 2008 at 08:38:09PM -0400, Chuck Robey wrote: >>> I don't know if this is important or not, and I won't harp on this, but I've >>> heard before that an attempt is made both to keep evdev.c very current, AND >>> to >>> have it not have anything in it that is Linux-only. >> >> I don't know where you heard the Linux-only bit, but it's completely >> wrong. evdev is a Linux-only API. > > Sorry, I can't parse what you wrote. You don't know where I heard that Xorg > is > Linux-only? Is that what you said? Xorg is not Linux only. However, the Xorg evdev driver is Linux only because the evdev kernel interface only exists on linux. If Solaris or *BSD or anyone else ever adopt the evdev kernel interface, then the driver will have to be suitably abstracted for portability. Until then, it's Linux only. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: events in evdev.c
On Thu, Sep 18, 2008 at 12:10:13 -0400, Chuck Robey wrote: > Sorry, I can't parse what you wrote. EVDEV IS LINUX ONLY. Is that clearer now? Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: events in evdev.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Stone wrote: > On Wed, Sep 17, 2008 at 08:38:09PM -0400, Chuck Robey wrote: >> I don't know if this is important or not, and I won't harp on this, but I've >> heard before that an attempt is made both to keep evdev.c very current, AND >> to >> have it not have anything in it that is Linux-only. > > I don't know where you heard the Linux-only bit, but it's completely > wrong. evdev is a Linux-only API. Sorry, I can't parse what you wrote. You don't know where I heard that Xorg is Linux-only? Is that what you said? My understanding *had been* that Xorg was trying to be compatible with as many Unixes as possible, and specifically avoid being Linux only, which is why seeing the depth of Linuxcode that is in your flagship input driver, evdev, surprised me so. I uderstood, from Peter's mail, that I'm wrong there, and the use of Linux-only ocde in that flagship driver was deliberate. Simply really surprised me, that's all. Or were you saying maybe that I was wrong stating that evdev.c had been made Linux only? All of the inclusions from Linux's input.h, which allows the Linux events interface, prove my point well enough, I think. Or, maybe you were saying I was wrong in thinking that you folks were trying to make Xorg not be Linux only? Damn, it's hard to comment when I can't figure out what you were saying. If I was correct, why don't you just let it go, then, we don't need to air this out any more, I was just surprised. > > Cheers, > Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjSfWUACgkQz62J6PPcoOl2hwCfac/CnW01X5PmCfq7vrU4m1SC ILoAn0kqIbgRgaPPpmz1cO3XX9wlOWmQ =DD4C -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: pixman: Branch 'master'
On Wed, Sep 17, 2008 at 12:59:14PM -0700, Jeff Muizelaar wrote:
> commit d0b181f347ef4720d130beee3f03196afbd28aba
> Author: Jeff Muizelaar <[EMAIL PROTECTED]>
> Date: Wed Sep 17 15:53:20 2008 -0400
>
> Add support for ARMv6 SIMD fastpaths.
Thanks for the patch, but, uh ...
> +#ifdef USE_ARM
> +
> +static inline pixman_bool_t pixman_have_arm(void) { return TRUE; }
> +
> +#else
> +#define pixman_have_arm() FALSE
> +#endif
This doesn't look like it'd work too well on armv5 or below. Any chance
of a run-time test, a la MMX?
Cheers,
Daniel
signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: events in evdev.c
On Wed, Sep 17, 2008 at 08:38:09PM -0400, Chuck Robey wrote: > I don't know if this is important or not, and I won't harp on this, but I've > heard before that an attempt is made both to keep evdev.c very current, AND to > have it not have anything in it that is Linux-only. I don't know where you heard the Linux-only bit, but it's completely wrong. evdev is a Linux-only API. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Raw mouse input is distorted
2008/9/18 Peter Hutterer <[EMAIL PROTECTED]>: > On Wed, Sep 17, 2008 at 09:26:08PM +0200, Simon Thum wrote: >> Maybe evdev works better? I seems there is a problem when both absolute >> AND relative axes are exposed, > > The reason for this is that there's a couple of popular devices > (keyboard/mouse combos) that claim to have both relative x/y axes and absolute > x/y axes simultaneously. > > You lose the ability to go past the min/max reported for x/y (which in my case > was 255/255). It can be fixed in the driver, but nobody volunteered for it > yet. > > If you feel like it: https://bugs.freedesktop.org/show_bug.cgi?id=17637 >From what I can see from the kernel code, my setup only generates EV_ABS events, but it is possible that the module reports that it can do relative events as well. Do you know what I should be looking for to see if the kernel reports that it can do relative movements? Can I somehow force the evdev driver to only accept absolute events? I'll see if I can find the time to look into fixing the issue, as I guess it could be related to my problems. But like everybody else I'm in lack of time, so I'm not sure if it'll be doable. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Raw mouse input is distorted
2008/9/18 Peter Hutterer <[EMAIL PROTECTED]>: > On Wed, Sep 17, 2008 at 06:46:17AM -0700, Hauberg wrote: >> Now, my problem is that X seems to somehow accelerate the output from the >> 'usbtouchscreen' module, so that when I move my finger to the left, the >> cursor moves about twice as far to the left as my finger did. This does not >> correspond to the output from the 'usbtouchscreen' module. So, I'm a bit >> confused here: does X place the cursor at the position outputted by the >> kernel, or does it do some fancy things? > > after a quick 30s peek into the evtouch driver: > it always inits x/y with a range of [0-1024]. you'd need to change this (in > EVTouchPreInit) to reflect the real range of the coordinates you post from the > driver module. I don't see this in the evtouch driver, but since I don't know much about X, this just might be my ignorance showing :-) In general, I really want to avoid using the evtouch driver as it is unmaintained. The only development on this driver appears to be done by the Debian people. So the actual place to get the evtouch source code is not the evtouch website, but actually the Debian package. This difference could also explain why I don't see the 1024 stuff in EVTouchPreInit. But I don't think I've been clear enough in my description of our system. One way to get a functional setup is to use the 'usbtouchscreen' kernel module and the evtouch X11 driver. This works fine for everyday use, but it is hard to perform calibration. Another way to get a potentially working setup (this is what I'm working on) is to alter the 'usbtouchscreen' kernel module such that it can read the calibration data, and actually provide actual screen coordinates. I have this working, such that I can give the kernel my calibration parameters, and it will emit mouse events that corresponds to actual screen coordinates. If I use the 'evdev' X11 driver to handle these mouse events the cursor moves faster (I think that's the best word I've got) than the output from the kernel. Instead of using the 'evdev' X11 driver I can use the evtouch driver, and tell it not to use the calibration data, and that works. But then I haven't gotten rid of the evtouch driver, which is my main motivation. > all events are posted as absolute from the evtouch driver > (xf86PostMotionEvent, xf86PostButtonEvent), which means they will get scaled > by the server into the screen space, i.e. if the screen has a resolution is > 2048, this means that the device coordinate 512 will map to the screen > coordinate 1024. > > This could be the reason for your scaling issue. Setting up the axes with the > right values should fix that. alternatively, you could make sure the kernel > driver pre-scales to a range of 0-1024. I've tried to make the kernel send events with x in [0, 1023] and y in [0, 1023], but that still behaves quite poorly. I'm sorry that I can't give a better explanation, but I know sooo little about X that I simply don't have the terminology. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Bug report submitted
Dear list, Am Donnerstag, den 18.09.2008, 09:41 +0100 schrieb Colin Guthrie: > Paul Menzel wrote: > > PS: I would be interested, what I did wrong (subject, form, …) so I did > > not get any answer, so that I will not make this mistake next time. A > > link to a webpage with the rules would also suffice. > > I don't think you did anything specifically wrong. > > I notice you don't have any monitor glue or modelines avaialble in your > xorg.conf. Ok, I will dig into those words on the WWW. > You should have a look at that. > http://www.intellinuxgraphics.org/dualhead.html Thanks, I will do this. Bests, Paul > > Col > > > -- > > Colin Guthrie > gmane(at)colin.guthr.ie > http://colin.guthr.ie/ > > Day Job: >Tribalogic Limited [http://www.tribalogic.net/] > Open Source: >Mandriva Linux Contributor [http://www.mandriva.com/] >PulseAudio Hacker [http://www.pulseaudio.org/] >Trac Hacker [http://trac.edgewall.org/] > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Bug report submitted
Paul Menzel wrote: > PS: I would be interested, what I did wrong (subject, form, …) so I did > not get any answer, so that I will not make this mistake next time. A > link to a webpage with the rules would also suffice. I don't think you did anything specifically wrong. I notice you don't have any monitor glue or modelines avaialble in your xorg.conf. You should have a look at that. http://www.intellinuxgraphics.org/dualhead.html Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Bug report submitted (was: Re: xf86-video-intel 2.4.1: Problems with 915GM and Asus VW222S)
Dear list, Am Mittwoch, den 03.09.2008, 22:21 +0200 schrieb Paul Menzel: > Am Dienstag, den 02.09.2008, 16:05 +0200 schrieb Paul Menzel: > > > I am the owner of an ASUS EeePC 701 4G and am not able to get the ASUS > > VW222S [2] as an external display going at a resolution of 1680 * 1050 > > over VGA, which is the only port available. > > I forgot to mention. > > 1. The ASUS EeePC 701 4G has an Intel 910 GML Express chipset. > 2. The monitor is working on my desktop PC with the openchrome driver. > > > PS: Please CC me, as I am not subscribed to the list. > > 3. I am subcsribed to the list ;) > > > Any ideas or hints where I could look? Do those > > (EE) intel(0): underrun on pipe A! > > have to do with this? I filed a bug report under [3]. Thanks, Paul PS: I would be interested, what I did wrong (subject, form, …) so I did not get any answer, so that I will not make this mistake next time. A link to a webpage with the rules would also suffice. > > [1] http://en.wikipedia.org/wiki/EeePC > > [2] > > http://www.asus.com/products.aspx?l1=10&l2=89&l3=362&l4=0&model=1741&modelmenu=1 [3] https://bugs.freedesktop.org/show_bug.cgi?id=17629 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: intel atom support
Many thanks for pointing me in the right direction ! I will check http://moblin.org/ to see if vaapi driver for US15W and a video application using that driver are already made. Thank you all, Carlos 2008/9/18 Austin Yuan <[EMAIL PROTECTED]>: > On Wed, Sep 17, 2008 at 10:34 PM, Roland Scheidegger > <[EMAIL PROTECTED]> wrote: >> On 17.09.2008 14:57, Carlos Ojea wrote: >>> Hello dudes! >>> >>> My board has an intel SCH wich incorporates integrated graphics and >>> video decode capabilities such as H.264. >>> I am wondering if the X driver (now I know it exists!) makes use of >>> that H.264 hardware decode capabilities so a media player could avoid >>> making all the decoding by software. >> >> Note that this can't work with XV. The driver (I don't think it would >> live in the X driver though) would need to support an API designed for >> offloading video decoding, hence intel's proposal of VAAPI >> (http://freedesktop.org/wiki/Software/vaapi). And the video players of >> course would need to support it too. >> I don't think this stuff has materialized yet... >> Your driver may support standard XV though for csc conversion/scaling. > As far as I know, Intel made vaapi driver and upper layer spliter a > reality, but I wonder if individuals have a chance to get them, > perhaps he can check http://moblin.org/ > > Austin >> >> Roland >> ___ >> 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
