[Xpert]Re: Matrox G550 and DDC problem
Greg Stark [EMAIL PROTECTED] writes: Which of these three is the default? Which is likely to work if the default isn't working? Given the excerpts from the log below it looks like like it's using DDC2? Should I try noDDC2 then? Incidentally I just tried noDDC2 and there was no change, it still loaded the I2C module and then failed to read any DDC info: (II) Loading sub module ddc (II) LoadModule: ddc (II) Reloading /usr/X11R6/lib/modules/libddc.a (II) Loading sub module i2c (II) LoadModule: i2c (II) Loading /usr/X11R6/lib/modules/libi2c.a (II) Module i2c: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.2.0 ABI class: XFree86 Video Driver, version 0.5 (==) MGA(0): Write-combining range (0xe800,0x100) (II) MGA(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x (II) MGA(0): I2C bus DDC initialized. (**) MGA(0): Option NoDDC2 (II) MGA(0): I2C Monitor info: (nil) (II) MGA(0): end of I2C Monitor info (--) MGA(0): No DDC signal (II) MGA(0): DDC Monitor info: (nil) (II) MGA(0): end of DDC Monitor info -- greg ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Radeon Mobility 7500 screen blank of death
XF86 Ver: Tested with 4.2.0-72 (RH8.0) and CVS (Nov8th), same result Hardware: - Dell Inspiron 4150 Laptop w/ A03 BIOS - i845 chipset - ATI Radeon Mobility M7 LW rev 0 Problem PreReq: Only manifests when laptop is running on battery power. Problem: When X is running and the keyboard/mouse isn't touched for about 5mins, the screen blanks. Pressing a key or moving the mouse causes to 'unblank', however, the screen is a dancing, scrambled, unreadable mess. Switching out to 'text mode' via CTL-ALT-F1 doesn't help, it is still scrambled. Note that the OS is not locked up; I can still SSH in. Rebooting the box is the only way to get the screen back to normal, just restarting X has no effect. Checking dmesg and the XFree86.0.log file shows no error messages, or any extra messages for that matter. Suggestions and help welcome. I'm happy to test patches and provide any detailed feedback/info. Log and Config below: XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-72) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-11smp i686 [ELF] Build Host: daffy.perf.redhat.com Module Loader present OS Kernel: Linux version 2.4.18-17.8.0 ([EMAIL PROTECTED]) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Tue Oct 8 13:51:08 EDT 2002 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/XFree86.0.log, Time: Sat Nov 9 22:20:14 2002 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Anaconda Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device ATI Radeon Mobility 7500 (**) |--Input Device Mouse0 (**) |--Input Device Mouse1 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7100 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8002183c, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1a30 card , rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a31 card , rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,2482 card 8086,4541 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev 42 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,248c card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,248a card 8086,4541 rev 02 class 01,01,8a hdr 00 (II) PCI: 00:1f:5: chip 8086,2485 card 1013,5959 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,2486 card 14f1,5421 rev 02 class 07,03,00 hdr 00 (II) PCI: 01:00:0: chip 1002,4c57 card 1028,012b rev 00 class 03,00,00 hdr 00 (II) PCI: 02:00:0: chip 10b7,9200 card 1028,012a rev 78 class 02,00,00 hdr 00 (II) PCI: 02:01:0: chip 104c,ac51 card 4000, rev 00 class 06,07,00 hdr 82 (II) PCI: 02:01:1: chip 104c,ac51 card 4800, rev 00 class 06,07,00 hdr 82 (II) PCI: 02:03:0: chip 104c,ac50 card 5000, rev 01 class 06,07,00 hdr 02 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0x - 0x (0x1) IX[B] (II) Bus 0
Re: [Xpert]Re: Matrox G550 and DDC problem
On 10 Nov 2002, Greg Stark wrote: Incidentally I just tried noDDC2 and there was no change, it still loaded the I2C module and then failed to read any DDC info: Which Matrox card is this ? Does X -configure report DDC info - that uses DDCvbe. Both DDC2 and DDCvbe work for me, and there are objections to both, so I've given up worrying about the fact that one is used with -configure, and the other for the real server. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Matrox G550 and DDC problem
On Sun, Nov 10, 2002 at 03:03:16AM -0500, Greg Stark wrote: Some monitors support DDC1 but not DDC2 and vice-versa. For our mga driver there are actually three DDC implementations: DDC1, DDC2 and DDCvbe. Each can be turned off separately in the Monitor Section of the config file, with one of: Option noDDC1 Option noDDC2 Option noDDCvbe This is fascinating, I had always wondered why my Matrox G400 can't read any DDC information from my Sony G500 (this gets confusing fast:). I can see that. ;-) I've had the same problem with my Matrox G400 on my old monitor, which is a ViewSonic PS790, and my new toy, a MAG Innovision 17 LCD. To wit, excerpts from /var/log/XFree86.log.0 using various Monitor sections. First, the Monitor section in use: Section Monitor Identifier Monitor0 VendorName ViewSonic ModelName PS790 Option DPMS VertRefresh 60-75 HorizSync 31-80 DisplaySize 337 270 EndSection Stock config (no DDC options set): ... (II) Loading sub module ddc (II) LoadModule: ddc (II) Reloading /usr/X11R6/lib/modules/libddc.a (II) Loading sub module i2c (II) LoadModule: i2c (II) Loading /usr/X11R6/lib/modules/libi2c.a (II) Module i2c: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.2.0 ABI class: XFree86 Video Driver, version 0.5 (==) MGA(0): Write-combining range (0xf200,0x200) (II) MGA(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x (II) MGA(0): I2C bus DDC initialized. (II) MGA(0): I2C device DDC:ddc2 registered. (II) MGA(0): I2C device DDC:ddc2 removed. (II) MGA(0): I2C Monitor info: (nil) (II) MGA(0): end of I2C Monitor info (--) MGA(0): No DDC signal (II) MGA(0): DDC Monitor info: (nil) (II) MGA(0): end of DDC Monitor info ... Specifying Option noDDC2: ... (II) Loading sub module ddc (II) LoadModule: ddc (II) Reloading /usr/X11R6/lib/modules/libddc.a (II) Loading sub module i2c (II) LoadModule: i2c (II) Loading /usr/X11R6/lib/modules/libi2c.a (II) Module i2c: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.2.0 ABI class: XFree86 Video Driver, version 0.5 (==) MGA(0): Write-combining range (0xf200,0x200) (II) MGA(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x (II) MGA(0): I2C bus DDC initialized. (**) MGA(0): Option NoDDC2 (II) MGA(0): I2C Monitor info: (nil) (II) MGA(0): end of I2C Monitor info (--) MGA(0): No DDC signal (II) MGA(0): DDC Monitor info: (nil) (II) MGA(0): end of DDC Monitor info ... Specifying Opton noDDC1: ... (II) Loading sub module ddc (II) LoadModule: ddc (II) Reloading /usr/X11R6/lib/modules/libddc.a (II) Loading sub module i2c (II) LoadModule: i2c (II) Loading /usr/X11R6/lib/modules/libi2c.a (II) Module i2c: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.2.0 ABI class: XFree86 Video Driver, version 0.5 (==) MGA(0): Write-combining range (0xf200,0x200) (II) MGA(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x (II) MGA(0): I2C bus DDC initialized. (**) MGA(0): Option NoDDC1 (II) MGA(0): I2C device DDC:ddc2 registered. (II) MGA(0): I2C device DDC:ddc2 removed. (II) MGA(0): I2C Monitor info: (nil) (II) MGA(0): end of I2C Monitor info (II) MGA(0): DDC Monitor info: (nil) (II) MGA(0): end of DDC Monitor info ... From X -configure: ... (II) Loading sub module vbe (II) LoadModule: vbe (II) Loading /usr/X11R6/lib/modules/libvbe.a (II) Module vbe: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (II) Loading sub module int10 (II) LoadModule: int10 (II) Loading /usr/X11R6/lib/modules/linux/libint10.a (II) Module int10: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (II) MGA(0): initializing int10 (II) MGA(0): Primary V_BIOS segment is: 0xc000 (II) MGA(0): VESA BIOS detected (II) MGA(0): VESA VBE Version 2.0 (II) MGA(0): VESA VBE Total Mem: 32768 kB (II) MGA(0): VESA VBE OEM: Matrox Graphics Inc. (II) MGA(0): VESA VBE OEM Software Rev: 1.5 (II) MGA(0): VESA VBE OEM Vendor: Matrox (II) MGA(0): VESA VBE OEM Product: Matrox G400 (II) MGA(0): VESA VBE OEM Product Rev: 00 (II) Loading sub module ddc (II) LoadModule: ddc (II) Loading /usr/X11R6/lib/modules/libddc.a (II) Module ddc: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (II) MGA(0): VESA VBE DDC supported (II) MGA(0): VESA VBE DDC Level 2 (II) MGA(0): VESA VBE DDC transfer in appr. 1 sec. (II) MGA(0): VESA VBE DDC read successfully ... Kurt -- Excellent day to have a rotten day. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Matrox G550 and DDC problem
On Sun, Nov 10, 2002 at 10:16:39AM +, Dr Andrew C Aitchison wrote: On 10 Nov 2002, Greg Stark wrote: Incidentally I just tried noDDC2 and there was no change, it still loaded the I2C module and then failed to read any DDC info: I get the same result. Which Matrox card is this ? A G400 here. Does X -configure report DDC info - that uses DDCvbe. Not here. Both DDC2 and DDCvbe work for me, and there are objections to both, so I've given up worrying about the fact that one is used with -configure, and the other for the real server. Neither works for me. Kurt -- When in doubt, do what the President does -- guess. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]logitech marble mouse
Hi, I have XFree4.2.0 and bought a Logitech Marble Mouse recently. This is actually a trackball with 2 normal buttons and 2 small buttons for scrolling. You can plug it in PS/2 or USB-Port. I don´t get the scrolling to work. The 2 normal buttons act normally, the left of the 2 small ones acts as third button and the right one has the same effect as the normal right mouse button. I tried different protocols and changing Buttons and ZAxisMapping settings in XF86Config but nothing helped. Now I use IMPS/2. I am able to do scrolling with the left small button (ZAxisMapping = 2 4) but the right small button is not recognized as 4th one, but is always the same as the normal right button. Can I do something to make it work, or is this rrackball simply not supported? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Xinerama.h in current XFree86 CVS
Hi all, I test the presence and usability of include/X11/extensions/Xinerama.h using a configure script. The script complains that the file is present but not usable. My looking at the Xinerama.h file, it doesn't include other X headers so Bool is not defined. That's why the configure scripts cannot compile its default test prog. Wouldn't be suitable to include Xlib.h (where Bool is defined) in Xinerama.h ? If I remember well, the problem did not arise in previous XFree86 versions (I'm using current XFree86 CVS). Thanks, Cheers, -- Olivier [EMAIL PROTECTED]http://www.xfce.org --- XFce is a lightweight desktop environment for various *NIX systems. Designed for productivity, it loads and executes applications fast, while conserving system resources. XFce is all free software, released under GNU General Public License.Available from http://www.xfce.org ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]AdjustFrame in XFree86-drivers
Hello, At the moment, some XFree86-drivers force synchronization with the vertical retrace of the CRT whenever AdjustFrame is called, whereas some drivers do not. I think that a uniform behaviour would be favorable. Tests have shown that the modifications necessary are trivial and that the modified drivers work properly and reliably. (Different people I know already tested that.) I asked Alan Hourihane about his opinion. He suggested some open discussion within the context of this mailing-list. So what is your opinion? Best Regards, Stefan -- Stefan Kralhttp://www.complang.tuwien.ac.at/skral/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Matrox G550 and DDC problem
On Sun, 10 Nov 2002 [EMAIL PROTECTED] wrote: From X -configure: (II) Loading sub module ddc (II) LoadModule: ddc (II) Loading /usr/X11R6/lib/modules/libddc.a (II) Module ddc: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (II) MGA(0): VESA VBE DDC supported (II) MGA(0): VESA VBE DDC Level 2 (II) MGA(0): VESA VBE DDC transfer in appr. 1 sec. (II) MGA(0): VESA VBE DDC read successfully That is a success; /root/XF86Config.new should have some info about the monitor. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]screen damage region extension
Hi, Here is a proof-of-concept rough cut at an extension to track damage regions for the screen (notify clients about pixels that have changed). Been thinking about this for a while in order to support desktop pagers with thumbnailing, but was finally inspired to write code by the krfb client-side VNC implementation http://www.tjansen.de/krfb/, a very useful application that right now has to poll pixels in a timeout. (http://xf4vnc.sourceforge.net/ is another possible approach for that specific app.) Aside from VNC the extension is useful for desktop pagers, magnifiers, whatever. All the screenshot hacks we're currently using due to Keith not finishing cool fast ways to do this stuff. ;-) The current code is very rough (debug printf's left in there, xedit commented out because I couldn't make it build, I didn't finish the Xrender bits in midamage.c, etc.) but does basically work for me. Code at http://people.redhat.com/~hp/xdamage.tar.gz for now, I'll append the README. Would appreciate any comments people have. As will be obvious from reading the code I'm pretty clueless about X server hacking. Havoc README The DAMAGE extension is an extension to track a damage region for the screen. i.e. each time a pixel on the screen changes, it's considered damage and reported to interested clients. This extension is intended to make screenshot hacks more viable. Screenshot hacks include a variety of applications such as screen magnifiers, screen thumbnailers (e.g. window manager pagers), and client-side VNC implementations. Without the damage extension, these applications have to poll the screen contents in a timeout, which typically uses too much CPU to be practical. The damage extension will probably become obsolete when the server has built-in facilities for syncing the contents of one window to another window or a shared image, including optional scaling prior to sync. Then a magnifier or thumbnailer simply sets up such an autosync relationship and displays the sync target. Interface === The damage extension is very simple; for each screen that supports damage reporting, a client can create any number of DamageRecorder resources. A DamageRecorder tracks a damage region for the screen. Each time the screen changes, the damaged area is added to the damage region. At any time the client can ask the DamageRecorder for the current damage region, or a sub-area of it. When the damage region is returned, it is also reset. The region is returned and reset in one step to avoid the obvious race condition. Each active DamageRecorder generates DamageNotify events when the damage region is updated. Interface Open Questions === 1) Should there be a single atomic operation to not only get and reset the damage region, but also GetImage the damage region? I don't *think* this is required for semantic correctness, though perhaps it eliminates an extra round trip. It looks annoying to implement though especially if shared images are optionally used. 2) What exactly are the semantics of DamageNotify events? Are they sent: a) whenever the damage region goes from empty to non-empty b) whenever the damage region changes c) whenever the bounding box of the damage region changes d) whenever the damage region changes, but with some (client-configurable?) rate limit e) whenever the damage region region changes by some (client-configurable?) area increment? Currently the implementation does b), but this creates a *lot* of events. Implementation === The implementation is a straight ripoff of misprite.c, as suggested by Keith Packard. It simply updates all damage regions when the screen changes, instead of hiding the sprite. But uses the same wrap-the-screen-and-gc-funcs code. To add support for the extension, drivers call miDamageInitialize() which wraps their screen functions. Right now I've only added miDamageInitialize() to the xnest driver. The wrappers check whether there are any active DamageRecorder objects before they do any real computation, so the overhead when not actively using the extension should be minimal. Implementation Open Questions === 1) Each driver should report whether it supports the extension, as some screens of a display can support it while others do not. Where/how should this be marked? In a devPrivate field on each screen? 2) Does it work? Need some way to comprehensively test midamage.c, need to check client/server with different byte order, etc. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]screen damage region extension
Havoc Pennington wrote: Hi, Here is a proof-of-concept rough cut at an extension to track damage regions for the screen (notify clients about pixels that have changed). Been thinking about this for a while in order to support desktop pagers with thumbnailing, but was finally inspired to write code by the krfb client-side VNC implementation http://www.tjansen.de/krfb/, a very useful application that right now has to poll pixels in a timeout. (http://xf4vnc.sourceforge.net/ is another possible approach for that specific app.) Interestingly enough, I was toying with a very similar idea, but for the purpose of implementing true window transparency and window deformations (a-la MacOS X ghosting) on the client side (i.e. via a special client, rather than by putting everything inside the X server). In addition to your extension, only one thing woud be required - ability for a client to flag certain windows as off-screen. Then off-screen windows would not be displayed, but the interesting client (which would be compositing manager, analogous to window manager) would track the changes. Then a compositing manager could just track window alpha pixmaps (referenced via atoms, probably) and, whenever a transparent window gets uncovered, it would move it off-screen along with all the windows it covers, put its own window in its place and pipe the contents by compositing or even deforming it from the off-screen pixmaps (using either OpenGL or XRender). Now if I get the time to write a proof-of-concept... Miro ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]SiS XVideo performance
Hi all, I recently released a video deinterlacer application called tvtime: http://tvtime.sourceforge.net/ which is a bit of a stress test for XVideo performance: we upload 720x480x59.94fps YUY2 for NTSC, and 720x576x50fps YUY2 for PAL. We just found a problem with SiS users. For one user, even though AGP 4x is active (or so it seems), frame uploads are taking a horribly long time. Between 15ms and 30ms for PAL-sized frames. I thought we had this problem last December, and it was because the driver spins waiting for the retrace: http://www.xfree86.org/pipermail/xpert/2001-December/014146.html Looking at the code in cvsweb, it looks like this is still the case. I guess no patch came out of that work? Was it rejected for some reason? One solution that was suggested to me was to not XFlush after doing XvShmPutImage, and just make sure tvtime runs at a higher priority. This works nicely for me, since if I'm run as root I run SCHED_FIFO among other things.. Or I could just grab a high priority and hope that works. Any comments on this solution? I haven't tried this out with the SiS user, but it seems to work o.k. for my G400 (but if I'm a user app without high priority then I drop frames). -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]two keyboards: Linux kernel patch and XInput driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 8 Nov 2002 10:20, Tim Wright wrote: snip I've almost finished patching the Linux HID Keyboard driver (2.4.19 kernel) so that it creates device nodes /dev/keyboards/keyboard?? for every USB keyboard. If you ignore these, then Linux functions as usual - all keyboard input streams are merged as the system keyboard. If you open one of these nodes, then events from that keyboard are sent through that node and are not sent to the system keyboard any more. I've written all that code except for reading from the nodes (open and close work fine). To quote Vojtech You shall not mangle events in the kernel. It is a bad idea to add the /dev/input/keyboards API. Your chances of getting it merged are very low. What you really want to do is to use /dev/input/eventX. In a moment of happiness, Zephaniah E. Hull [EMAIL PROTECTED] even posted a driver for this to the Xpert list. That driver needs to be generalised, but it is along the right track. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9zs24W6pHgIdAuOMRApN6AKCNQjEx3vAMzghDZEbQqbFGtq/YdACgm3pF lvkP2J2dg84vc/1a8oastEo= =WVRm -END PGP SIGNATURE- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]change input device on the fly?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 8 Nov 2002 09:35, Warren Turkal wrote: Now try to use a wacom tablet with that. Don't top quote, even if you think you know what you are doing. On Thursday 07 November 2002 10:56 am, Michel Dänzer wrote: On Don, 2002-11-07 at 17:47, Adam Luter wrote: Not an expert, but have you tried to specify both devices at the same time? You may still have to restart X, Not if you use /dev/input/mice for the USB mouse. I actually have an answer to this, which basically provides a kernel config option to disable the mousedev driver claiming the tablet. You'd still need to have a suitable driver (eg the wacom X driver). Would that solve your problem? Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9zs5/W6pHgIdAuOMRAioMAJ49vRYGuaRkReV7sJU0vdPP1IIrKgCfZo8c ZOQUg2/3VpUYyvfU/ysWfsY= =niM/ -END PGP SIGNATURE- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SiS XVideo performance
Thomas Winischhofer ([EMAIL PROTECTED]): The sis driver will be heavily updated within the next few weeks, with the code from www.winischhofer.net/linuxsis630.shtml. Good to hear! My just don't XFlush fix didn't work anyway, causes tearing with the mga driver :) I updated the tvtime bug report to point to your page. Thanks, -Billy -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Option Rotate doesn't work
Some drivers have Option Rotate, they would swap the width and height passed to fbScreenInit, subsequently, this would result in the root window size being rotated. However, this no longer works. Swapping the width and height passed to fbScreenInit does not change the root window size in the ConnectionBlock, and subsequently Rotate capable drivers like nv break. How are drivers supposed to change the advertised root window size now? Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]AdjustFrame in XFree86-drivers
On Son, 2002-11-10 at 19:42, Kral Stefan wrote: At the moment, some XFree86-drivers force synchronization with the vertical retrace of the CRT whenever AdjustFrame is called, whereas some drivers do not. I think that a uniform behaviour would be favorable. Tests have shown that the modifications necessary are trivial and that the modified drivers work properly and reliably. (Different people I know already tested that.) Have you tested the radeon driver with page flipping? I see a conflict there, page flipping requires updates to the CRTC offset to take effect immediately. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]Scanpci.out for HP LE1230 laptop
Title: RE: [Xpert]Scanpci.out for HP LE1230 laptop According to http://www.yourvote.com/pci and http://bongolia.org/linux/mitac7321.php#graphics the chiset is coedenamed S3 Twister K and this should be an S3 Savage 4. You can bring it to live with the generic VESA driver, maybe frambuffer driver works as well, but the specially designed Savage driver should work best for it. Dont blame me for anything bogus or not working, i just did some simple research on your topic. I am not using that board or Laptop. -Alex. -Original Message- From: Calvin Arndt [mailto:[EMAIL PROTECTED]] Sent: Friday, November 08, 2002 16:24 To: [EMAIL PROTECTED] Subject: [Xpert]Scanpci.out for HP LE1230 laptop I attempted to configure Xfree86 4.2.99 yesterday. #XFree86 -configure reported an unkown card (some flavor of S3) and requested scanpci -v output Here it is... Please send any comments to calarndt at tux4kids dot org pci bus 0x cardnum 0x00 function 0x00: vendor 0x1106 device 0x0305 VIA Device unknown CardVendor 0x103c card 0x0022 (HP, Card unknown) STATUS 0x2210 COMMAND 0x0006 CLASS 0x06 0x00 0x00 REVISION 0x80 BIST 0x00 HEADER 0x00 LATENCY 0x48 CACHE 0x00 BASE0 0xa008 addr 0xa000 MEM PREFETCHABLE pci bus 0x cardnum 0x01 function 0x00: vendor 0x1106 device 0x8305 VIA Device unknown STATUS 0xa230 COMMAND 0x0007 CLASS 0x06 0x04 0x00 REVISION 0x00 HEADER 0x01 LATENCY 0x00 PRIBUS 0x00 SECBUS 0x01 SUBBUS 0x01 SECLT 0x00 IOBASE 0xc000 IOLIM 0xdfff SECSTATUS 0x NOPREFETCH_MEMBASE 0xe000 MEMLIM 0xefff PREFETCH_MEMBASE 0x9000 MEMLIM 0x9fff NO_FAST_B2B NO_SEC_BUS_RST NO_M_ABRT VGA_EN NO_ISA_EN NO_SERR_EN NO_PERR_EN pci bus 0x cardnum 0x0a function 0x00: vendor 0x1217 device 0x6972 Device unknown STATUS 0x0410 COMMAND 0x0087 CLASS 0x06 0x07 0x00 REVISION 0x00 BIST 0x00 HEADER 0x02 LATENCY 0x40 CACHE 0x00 BASE0 0x1000 addr 0x1000 MEM BASE1 0x02a0 addr 0x02a0 MEM BASE2 0x40020200 addr 0x40020200 MEM BASE3 0x0d00 addr 0x0d00 MEM BASEROM 0x10fd addr 0x decode-enabled MAX_LAT 0x00 MIN_GNT 0xc0 INT_PIN 0x01 INT_LINE 0x0b BYTE_0 0x22103c BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00 pci bus 0x cardnum 0x0c function 0x00: vendor 0x104c device 0x8026 Texas Instruments Device unknown STATUS 0x8210 COMMAND 0x CLASS 0x0c 0x00 0x10 REVISION 0x00 BIST 0x00 HEADER 0x00 LATENCY 0x48 CACHE 0x00 BASE0 0x10001000 addr 0x10001000 MEM BASE1 0x10004000 addr 0x10004000 MEM MAX_LAT 0x04 MIN_GNT 0x02 INT_PIN 0x01 INT_LINE 0x00 pci bus 0x cardnum 0x11 function 0x00: vendor 0x1106 device 0x8231 VIA Device unknown CardVendor 0x103c card 0x0022 (HP, Card unknown) STATUS 0x0210 COMMAND 0x008f CLASS 0x06 0x01 0x00 REVISION 0x10 BIST 0x00 HEADER 0x80 LATENCY 0x00 CACHE 0x00 BYTE_0 0x20f4 BYTE_1 0x00 BYTE_2 0x8072a20 BYTE_3 0x pci bus 0x cardnum 0x11 function 0x01: vendor 0x1106 device 0x0571 VIA VT 82C586 MVP3 IDE Bridge CardVendor 0x103c card 0x0022 (HP, Card unknown) STATUS 0x0290 COMMAND 0x0007 CLASS 0x01 0x01 0x8a REVISION 0x06 BIST 0x00 HEADER 0x00 LATENCY 0x40 CACHE 0x00 BASE4 0x1101 addr 0x1100 I/O BYTE_0 0x3a09f203 BYTE_1 0x00 BYTE_2 0x8072d98 BYTE_3 0x pci bus 0x cardnum 0x11 function 0x02: vendor 0x1106 device 0x3038 VIA VT 82C586 MVP3 USB Controller CardVendor 0x103c card 0x0022 (HP, Card unknown) STATUS 0x0210 COMMAND 0x0007 CLASS 0x0c 0x03 0x00 REVISION 0x1e BIST 0x00 HEADER 0x00 LATENCY 0x16 CACHE 0x00 BASE4 0x1201 addr 0x1200 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x04 INT_LINE 0x0b BYTE_0 0x31200 BYTE_1 0x00 BYTE_2 0x8073110 BYTE_3 0x pci bus 0x cardnum 0x11 function 0x04: vendor 0x1106 device 0x8235 VIA Device unknown CardVendor 0x103c card 0x0022 (HP, Card unknown) STATUS 0x0290 COMMAND 0x CLASS 0x06 0x80 0x00 REVISION 0x10 BYTE_0 0x5984a0 BYTE_1 0x00 BYTE_2 0x8073488 BYTE_3 0x pci bus 0x cardnum 0x11 function 0x05: vendor 0x1106 device 0x3058 VIA VT 8501 MVP4 MultiMedia CardVendor 0x103c card 0x0022 (HP, Card unknown) STATUS 0x0210 COMMAND 0x0001 CLASS 0x04 0x01 0x00 REVISION 0x40 BASE0 0xe001 addr 0xe000 I/O BASE1 0xe101 addr 0xe100 I/O BASE2 0xe105 addr 0xe104 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x03 INT_LINE 0x0a BYTE_0 0x1c00c001 BYTE_1 0x00 BYTE_2 0x8073800 BYTE_3 0x pci bus 0x cardnum 0x11 function 0x06: vendor 0x1106 device 0x3068 VIA VT 8501 MVP4 Modem CardVendor 0x103c card 0x0022 (HP, Card unknown) STATUS 0x0210 COMMAND 0x0001 CLASS 0x07 0x80 0x00 REVISION 0x20 BASE0 0xe201 addr 0xe200 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x03 INT_LINE 0x0a BYTE_0 0x1c00c001 BYTE_1 0x00 BYTE_2 0x8073b78 BYTE_3 0x pci bus 0x cardnum 0x12 function 0x00: vendor 0x1106 device 0x3065 VIA Device unknown CardVendor 0x103c card 0x0022 (HP, Card unknown) STATUS 0x0210 COMMAND 0x0001 CLASS
RE: [Xpert]Linux input patch.
Title: RE: [Xpert]Linux input patch. This patch (attached) add support under Linux for talking to mice directly from the event interface, IE, /dev/input/eventn. It is stashed as a os specific protocol, evdev, the Device option is not a device, but instead is the device name, such as 'A4Tech USB Optical Mouse'. It has some limits, specificly if you unplug a USB mouse and plug it back in you have to cause it to be deactivated and reactivated, a good way of doing that is to change VTs away from X, and then change back. Also if you have two identical mice with the same label it is somewhat indeterminate which you will get, this could be improved. If i do remember right i have seen an USB mice that provides a serial number trough its device information which uniqely identifies it. Sorry if i am wrong for this - its just what i thought i have seen there. -Alex.
RE: [Xpert]Do you know where XScript is now?
Title: RE: [Xpert]Do you know where XScript is now? I used some of the multiple ftp search engines on the web. I went to http://www.alltheweb.com and select the last tab in the title bar... (Ask yahoo for some more URLs of ftp search eangines.) There i got 4 hits for xscript.tar.gz, all dated from Februar 1994. The ftp trees are labeled as X11R5 (we are at X11R6 for a really long time) or you will find the files in pub7/NetBSD. No wonder, that no one knows about specific locations of XScript and the original location does no longer work at all. I opened them via clicking and found the download working for ftp.rge.com (X11 tree) ftp.sunset.se (X11 tree) ftp.man.szczecin.pl (NetBSD tree) All opened archives are same size and had no problems. -Alex. -Original Message- From: Marco Fioretti [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 09, 2002 05:53 To: [EMAIL PROTECTED] Subject: [Xpert]Do you know where XScript is now? Hello, I am trying to download the XScript utilities mentioned at this URL: http://jan.netcomp.monash.edu.au/SW.html#XScript I connect to the FTP server mentioned in that paragraph, and just nothing happens. My connection is OK, and I can download stuff from other sites, but on that URL *nothing* (not even errors) happen. Going there by hand shows that the directory is not there anymore. Do you know if that source code is still available somewhere else? I've spent all this afternoon querying google in the strangest ways to no avail... For the record, I also wrote to the author, without success. TIA, Marco Fioretti
Re: [Xpert]Linux input patch.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 11 Nov 2002 10:43, Alexander Stohr wrote: This patch (attached) add support under Linux for talking to mice directly from the event interface, IE, /dev/input/eventn. It is stashed as a os specific protocol, evdev, the Device option is not a device, but instead is the device name, such as 'A4Tech USB Optical Mouse'. It has some limits, specificly if you unplug a USB mouse and plug it back in you have to cause it to be deactivated and reactivated, a good way of doing that is to change VTs away from X, and then change back. Also if you have two identical mice with the same label it is somewhat indeterminate which you will get, this could be improved. If i do remember right i have seen an USB mice that provides a serial number trough its device information which uniqely identifies it. Sorry if i am wrong for this - its just what i thought i have seen there. Serial numbers are optional for USB devices (and most mice don't have such a thing). Also, some devices have them, but they are not unique (this is against spec). The name that comes back from EVIOCGNAME may not have meaningful text either, since some mice don't have any strings. You may get a null string, depending on the mouse type (won't happen on USB - you'll get the vendor and product IDs instead). There is really only one unique identifier that is reliably useful: the physical path, as returned by EVIOCGPHYS. For example, there will always be one device like this: usb-00:01.2-2.1/input0 However if you plug it into another port (or you plug another input device into that port), you are basically screwed. It'd still be a nice option to offer for configuration though. We still need proper hotplugging though. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9zv/lW6pHgIdAuOMRAu5YAKCCd5Ymuq5dNiiy7YqPrMXwj1c3XwCgqHKV SNK5fPBc4IhJecJPxPnFiMo= =R5eU -END PGP SIGNATURE- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon Mobility 7500 screen blank of death
From: Dax Kelson [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Date: Sun, 10 Nov 2002 01:16:21 -0700 (MST) XF86 Ver: Tested with 4.2.0-72 (RH8.0) and CVS (Nov8th), same result Hardware: - Dell Inspiron 4150 Laptop w/ A03 BIOS - i845 chipset - ATI Radeon Mobility M7 LW rev 0 Problem PreReq: Only manifests when laptop is running on battery power. Problem: When X is running and the keyboard/mouse isn't touched for about 5mins, the screen blanks. Pressing a key or moving the mouse causes to 'unblank', however, the screen is a dancing, scrambled, unreadable mess. Switching out to 'text mode' via CTL-ALT-F1 doesn't help, it is still scrambled. Note that the OS is not locked up; I can still SSH in. Rebooting the box is the only way to get the screen back to normal, just restarting X has no effect. Checking dmesg and the XFree86.0.log file shows no error messages, or any extra messages for that matter. Suggestions and help welcome. I'm happy to test patches and provide any detailed feedback/info. 1400x1050 display, right? I have the same problem on my IBM T30 with the same display and Radeon Mobility M7 LW. A real pain, but possible to recover from (at least on my system) without a reboot. To avoid the problem, try to switch to a text screen (CTRL-ALT-F2) before leaving the display. That will allow you to wake the display and enter ALT-F9 to get back to X. If you forget or can't, switch to a text display (which is messed up) and turn the display off (Fn-F3 on my IBM). Turn the display back on and the display will be back in sync. ALT-F9 to get back to X. This seems to be a timing issue. It looks like the screen wants to be powered on for a bit before the display is driven at 1400x1050. When I wake the display with widows, I seem to notice a delay after the light comes on before the display is un-blanked. This is a guess. The same happens to be after a suspend, but I don't think this is too common and I think it can be fixed by adjust ing a delay in apm.c. But the screen turn-off problem seems out of APM's domain. (Spoken by someone with minimal knowledge of APM.) Hope this helps, and I'd love to find a real fix for the problem. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Matrox G550 and DDC problem
On Sun, Nov 10, 2002 at 07:05:49PM +, Dr Andrew C Aitchison wrote: On Sun, 10 Nov 2002 [EMAIL PROTECTED] wrote: From X -configure: (II) Loading sub module ddc (II) LoadModule: ddc (II) Loading /usr/X11R6/lib/modules/libddc.a (II) Module ddc: vendor=The XFree86 Project compiled for 4.2.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (II) MGA(0): VESA VBE DDC supported (II) MGA(0): VESA VBE DDC Level 2 (II) MGA(0): VESA VBE DDC transfer in appr. 1 sec. (II) MGA(0): VESA VBE DDC read successfully That is a success; /root/XF86Config.new should have some info about the monitor. Some, but not much. Section Monitor #DisplaySize 330 270 # mm Identifier Monitor0 VendorName AY_ ModelName2fd Option DPMS EndSection Kurt -- Down with categorical imperative! ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Linux input patch.
On Mon, Nov 11, 2002 at 11:55:00AM +1100, Brad Hards wrote: On Mon, 11 Nov 2002 10:43, Alexander Stohr wrote: This patch (attached) add support under Linux for talking to mice directly from the event interface, IE, /dev/input/eventn. It is stashed as a os specific protocol, evdev, the Device option is not a device, but instead is the device name, such as 'A4Tech USB Optical Mouse'. It has some limits, specificly if you unplug a USB mouse and plug it back in you have to cause it to be deactivated and reactivated, a good way of doing that is to change VTs away from X, and then change back. Also if you have two identical mice with the same label it is somewhat indeterminate which you will get, this could be improved. If i do remember right i have seen an USB mice that provides a serial number trough its device information which uniqely identifies it. Sorry if i am wrong for this - its just what i thought i have seen there. Serial numbers are optional for USB devices (and most mice don't have such a thing). Also, some devices have them, but they are not unique (this is against spec). The name that comes back from EVIOCGNAME may not have meaningful text either, since some mice don't have any strings. You may get a null string, depending on the mouse type (won't happen on USB - you'll get the vendor and product IDs instead). There is really only one unique identifier that is reliably useful: the physical path, as returned by EVIOCGPHYS. For example, there will always be one device like this: usb-00:01.2-2.1/input0 Hmm, obviously this makes my current identification method rather suboptimial. What about using the bus, vendor, product, and version tags? (Returned by EVIOCGID) The main catch is that I don't have a clue what those would be set to for ADB or PS2 mice for 2.5.x. However if you plug it into another port (or you plug another input device into that port), you are basically screwed. It'd still be a nice option to offer for configuration though. We still need proper hotplugging though. We /can't/ support proper hotplugging under linux because to my knowledge no interface exists that can tell us that a new device has been plugged in. This really sucks, but it is beyond the scope of this patch to try and make that happen, though it is clearly something that must happen. (I have some thoughts on what might work, but they seem USB specific.) Zephaniah E. Hull. -- 1024D/E65A7801 Zephaniah E. Hull [EMAIL PROTECTED] 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. VOICE MODE=Pitr So, you are thinking am Communist ? Deal, Comerade ! /VOICE -- Chris on ASR. msg10721/pgp0.pgp Description: PGP signature
Re: [Xpert]Linux input patch.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 11 Nov 2002 14:43, Zephaniah E. Hull wrote: On Mon, Nov 11, 2002 at 11:55:00AM +1100, Brad Hards wrote: On Mon, 11 Nov 2002 10:43, Alexander Stohr wrote: This patch (attached) add support under Linux for talking to mice directly from the event interface, IE, /dev/input/eventn. It is stashed as a os specific protocol, evdev, the Device option is not a device, but instead is the device name, such as 'A4Tech USB Optical Mouse'. It has some limits, specificly if you unplug a USB mouse and plug it back in you have to cause it to be deactivated and reactivated, a good way of doing that is to change VTs away from X, and then change back. Also if you have two identical mice with the same label it is somewhat indeterminate which you will get, this could be improved. If i do remember right i have seen an USB mice that provides a serial number trough its device information which uniqely identifies it. Sorry if i am wrong for this - its just what i thought i have seen there. Serial numbers are optional for USB devices (and most mice don't have such a thing). Also, some devices have them, but they are not unique (this is against spec). The name that comes back from EVIOCGNAME may not have meaningful text either, since some mice don't have any strings. You may get a null string, depending on the mouse type (won't happen on USB - you'll get the vendor and product IDs instead). There is really only one unique identifier that is reliably useful: the physical path, as returned by EVIOCGPHYS. For example, there will always be one device like this: usb-00:01.2-2.1/input0 Hmm, obviously this makes my current identification method rather suboptimial. Depends on the problem we need to solve. If the machine only has one of each device, then it doesn't matter where it is plugged in, and we can use EVIOCGNAME or EVIOCGID. If the machine is multi-headed, then perhaps the physical path will be better. What about using the bus, vendor, product, and version tags? (Returned by EVIOCGID) That isn't different to using the strings on USB, except for the odd case where the string just says mouse or something silly. The main catch is that I don't have a clue what those would be set to for ADB or PS2 mice for 2.5.x. They will exist, but may not be unique (same as if you have two identical mice). There is an ioctl() for a unique identifier (EVIOCGUNIQ), but on most devices, it'll return NULL. However if you plug it into another port (or you plug another input device into that port), you are basically screwed. It'd still be a nice option to offer for configuration though. We still need proper hotplugging though. We /can't/ support proper hotplugging under linux because to my knowledge no interface exists that can tell us that a new device has been plugged in. Ah, but there is. /sbin/hotplug will be invoked by the linux kernel whenever a new device is attached or an existing device is detached. All the interesting devices can do this. You get the device information as environment variables. /sbin/hotplug is normally a script, but it can be anything. Or the script can exec() some other code. See http://linux-hotplug.sf.net This really sucks, but it is beyond the scope of this patch to try and make that happen, though it is clearly something that must happen. I see your patch as a first step, and one that is very welcome. Next thing would be to generalise the interface to work for a keyboard. (I have some thoughts on what might work, but they seem USB specific.) Unfortunately /sbin/hotplug is Linux specific. I don't know if the *BSD guys have something similar. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9zy5BW6pHgIdAuOMRArDPAKCBvm8h98Esn1l3pfnOwsud21JESgCdEzQA tPZkMLNgzrw/V6SZBNMr/aE= =AbD5 -END PGP SIGNATURE- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Linux input patch.
On Mon, Nov 11, 2002 at 03:12:49PM +1100, Brad Hards wrote: snip Hmm, obviously this makes my current identification method rather suboptimial. Depends on the problem we need to solve. If the machine only has one of each device, then it doesn't matter where it is plugged in, and we can use EVIOCGNAME or EVIOCGID. If the machine is multi-headed, then perhaps the physical path will be better. What about using the bus, vendor, product, and version tags? (Returned by EVIOCGID) That isn't different to using the strings on USB, except for the odd case where the string just says mouse or something silly. The main catch is that I don't have a clue what those would be set to for ADB or PS2 mice for 2.5.x. They will exist, but may not be unique (same as if you have two identical mice). There is an ioctl() for a unique identifier (EVIOCGUNIQ), but on most devices, it'll return NULL. Hmm, this is really starting to tell me that we need the ability to specify any of these, not too hard, I think. However if you plug it into another port (or you plug another input device into that port), you are basically screwed. It'd still be a nice option to offer for configuration though. We still need proper hotplugging though. We /can't/ support proper hotplugging under linux because to my knowledge no interface exists that can tell us that a new device has been plugged in. Ah, but there is. /sbin/hotplug will be invoked by the linux kernel whenever a new device is attached or an existing device is detached. All the interesting devices can do this. You get the device information as environment variables. /sbin/hotplug is normally a script, but it can be anything. Or the script can exec() some other code. See http://linux-hotplug.sf.net Judging from the existing hotplug code, I think the thing to do would be to have X listen on a FIFO or socket, and just have the scripts dump that information to the FIFO/socket. The real trick is getting X to listen on it, and activate and deactivate drivers based on it. Sadly, that is a good bit beyond my knowledge of X internals, and documentation is, not exactly present as far as I can find. This really sucks, but it is beyond the scope of this patch to try and make that happen, though it is clearly something that must happen. I see your patch as a first step, and one that is very welcome. Next thing would be to generalise the interface to work for a keyboard. Hmm, it is currently using the mouse framework for two reasons, the first is that it is what the other code I was basing it off of was for. The second is a bit more tricky, the mouse framework has things like the axis mapping, and button remapping, and while that could be reimplemented, I've never been a fan of code duplication. (I have some thoughts on what might work, but they seem USB specific.) Unfortunately /sbin/hotplug is Linux specific. I don't know if the *BSD guys have something similar. OTOH, the BSD guys already have HID layer support for mice at least, so a little less of a problem. Not a lot I can do about that, not having a *BSD system. Zephaniah E. Hull. -- 1024D/E65A7801 Zephaniah E. Hull [EMAIL PROTECTED] 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. Emergency medicine: It's like sysadminning, but with better LARTs and more blood. -- Mike Sugimoto on ASR. msg10723/pgp0.pgp Description: PGP signature
Re: [Xpert]Do you know where XScript is now?
On Mon, Nov 11, 2002 01:24:03 at 01:24:03AM +0100, Alexander Stohr wrote: I used some of the multiple ftp search engines on the web. . There i got 4 hits for xscript.tar.gz, all dated from Februar 1994. . I had already found same of those URLs, and downloaded the file but it contains some X test tools, not Jan Newmarch stuff. I apologize for not saying it explicitly in my original message. In the meantime, however, I've been pointed to Xdialog, so I'll use that, since it's much more recent and still being worked on. Thanks a lot to everybody who answered! Marco Fioretti ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
