[ANNOUNCE] xf86-video-mach64 6.8.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aaron Plattner (1):
Make sure the screen is a mach64 screen before doing anything in
ATIMach64XVInitialiseAdaptor.
Adam Jackson (1):
Don't print the resource list on failure.
Alan Coopersmith (3):
Add README with pointers to mailing list, bugzilla git repos
Convert to XORG_CWARNFLAGS XORG_CHANGELOG
Version 6.8.1
Paulo Cesar Pereira de Andrade (1):
Remove xf86{Disable,Enable}Interrupts
git tag: xf86-video-mach64-6.8.1
http://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.8.1.tar.bz2
MD5: 0856d9c8435cf4350b68fbd57ca6d4fc
SHA1: b5a811372e8624eeb3c53b8a53eecf24eec88420
http://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.8.1.tar.gz
MD5: 4893de8d172d81e3d269e15d6b4c24d5
SHA1: 5f1f7cda9a17c9d1cddbca38db6631ca1e1e6878
- --
-Alan Coopersmith- alan.coopersm...@sun.com
Sun Microsystems, Inc. - X Window System Engineering
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (SunOS)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkn4+swACgkQovueCB8tEw4cMACfd/a2UO8/J2WmfoTUpNdeVyWR
NdoAnjHg2okJyjiGxqUqW6xrREB7xO8X
=flGN
-END PGP SIGNATURE-
___
xorg-announce mailing list
xorg-announce@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: Xorg and multiple graphics cards
also sprach Tiago Vignatti vigna...@freedesktop.org [2009.04.29.0422 +0200]: Yeah, I'm trying to solve part of this. Great, I will definitely try to help, but it will take me a few days. I will study the bugs and reply to them, but also keep the list in the loop, okay? -- martin | http://madduck.net/ | http://two.sentenc.es/ arrogance on the part of the meritorious is even more offensive to us than the arrogance of those without merit: for merit itself is offensive. -- friedrich nietzsche spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Detecting the used keyboard driver
The XClient is not doing the wrong thing. I am not talking about an X keycode to X key symbol binding. The first program changes the kernel keycode (so not the X keycode), that is bound by the keyboard driver inside the kernel, to the scancode of a key. The when a key is pressed, the kernel driver receives the scancode from the physical keyboard. It then translates this scancode to the kernel keycode, which it then sends to the X server. The (driver inside) X server receives this kernel keycode that it then converts to an X keycode. For the evdev X input driver for example: X_keycode = 8 + kernel_keycode My program does not bind an X key symbol to the X keycode, since that is not needed for grabbing a key (XGrabKey() takes the key's keycode as an argument). - Marvin On Wed, Apr 29, 2009 at 12:14 AM, Peter Hutterer peter.hutte...@who-t.net wrote: On Tue, Apr 28, 2009 at 11:10:57AM +0200, Marvin Raaijmakers wrote: Well I developed keyTouch, a program that allows the user to bind actions to extra function keys (like the Play/Pause, WWW or Zoom keys for example) on a keyboard. KeyTouch is a collection of programs. One program binds a key's scancode to a Linux keycode. So it changes the mapping inside the Linux kernel. Another program is an X client and grabs all key events of the extra function keys. So this program needs to know the X keycodes of the keys and thus it will have to translate the kernel keycode to the X keycode. These translations are different when the evdev input driver is used by the X server instead of the kbd driver. This sounds like the X client is doing the wrong thing. It should get the mapping from the server and then bind to the correct keysym. The only thing a keycode tells you is that it is the e.g. 5th key in the second row. And even that you have to guess. What do you mean by query the keyboards for all properties? Using XListInputDevices? Then there need to be different values for min_keycode, max_keycode or num_keys (or am I wrong?). These are however the same for evdev and kbd. XListDeviceProperties() Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Griffin Powermate evdev setup
I'd like to ask a more general question about devices which, like the Powermate, don't really fit into either the Keyboard or Pointing device classes: To what extent *should* X support these devices? Let's examine a ShuttlePro - a jog wheel, a spinner, 15 buttons. It's not really a keyboard, as the buttons don't really have any defined mapping other than Button 1 ... Button 15. It's not a pointing device. Applications like Kino recognize it and can use it to do editing control, in which case the jog wheel and the spinner are logically distinct from the mouse's wheel. Kino supports this device by going directly to the underlying /dev/input/event device, and not through X. Now, that works - and perhaps that is how it should be: X concerns itself with pointers and keyboards, and we let other things be handled outside of X. HOWEVER, that approach has several problems: 1) No remote access: I cannot run a program on another machine and have it use the Shuttle unless the Shuttle is supported by X. 2) No arbitration between applications: If Kino and some other program Foo both understand the Shuttle and want to use it, and I change input focus from Kino to Foo, how do we route the events correctly? Do the programs close the device when the lose input focus, and re-open it when the regain focus? Do they ignore events when not focused? 3) Less portable code - going to /dev/input/event5 may be fine under Linux, but is it supported under the *BSD kernels? under the Mac's X server? under Solaris/Irix/AIX? You can generalize this to things like joysticks and game pads - as far as I can see, there is little difference between a Shuttle and my PS3 DualShock as far as things like this go. Has there been a design decision where support for devices like this should live? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel: 2.7.99.1 snapshot (now with 10% reduced fat!)
'Twas brillig, and Carl Worth at 29/04/09 04:49 did gyre and gimble: We definitely want to make any such confirmed bugs a priority, so it would be nice to have a consistent mechanism to search for these bugs. Suggestions are welcome on the best approach. How about using the Whiteboard to enter in a git tag name? In an ideal world, it would be great if bugzilla was tied to the git repo for a given component and could parse the tags and display them in a drop down but that's probably going to require too much hacking on bz itself to be practicable right now. Something like: xf86-video-intel:2.7.99.1 would be a good whiteboard tag, then you can search for xf86-video-intel:2.7.99 and still get all the sub-releases etc. That said, it may be a bit too complicated to expect people to do this :s 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
Re: Re: After an update I get error message no screens found
Hello Tiago, I updated my system and after a reboot the Xserver failed to start. I got the message: (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found I tried the new unmodified xorg.conf and my old working xorg.conf (attached) configuration and I got the same error (logfile attached). What's wrong? rm -rm xorg.conf and start the X server again. I tried an empty xorg.conf and I get the same error. I'll try it with a removed xorg.conf when I'm at home but I think it'll be the same. Thank you for responding Marco Arcor.de Gaming Area - kostenfrei daddeln bis der Arzt kommt! Jetzt checken und aus über 80 Spielen wählen! http://www.arcor.de/footer-gaming/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Re: After an update I get error message no screens found
Hello Julien, sorry for the delayed response. The X pci stuff is busted on sparc in lenny. You'll have to either use a framebuffer driver, or upgrade to unstable. Thanks for the hint. I'll try this. Thanks for responding. Marco Arcor.de Gaming Area - kostenfrei daddeln bis der Arzt kommt! Jetzt checken und aus über 80 Spielen wählen! http://www.arcor.de/footer-gaming/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Old System, New Install Isuue
Date: Tue, 28 Apr 2009 16:55:13 -0700 From: James Butler jbut...@uniteddefensegroup.com Alan Coopersmith wrote: James Butler wrote: Is it possible to run X without an attached monitor, mouse or keyboard? Xfb sounds like it would work for me. Basically I need something that will run continuously in the background (daemon-like), rather than during a VNC session. Xvnc can be run continuously, daemon-like. I do it all the time. I've never used Xvfb, so I can't say which is better. - Patrick ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel: 2.7.99.1 snapshot (now with 10% reduced fat!)
Carl Worth schrieb: This is a development snapshot very early in the process toward developing 2.8. There have been some big changes to the code, and we're anxious to get feedback on these changes as early as possible. Here is a summary of the biggest changes: * Driver now depends on X server 1.6 or later * Eliminate XAA and EXA support (in favor of UXA) * Eliminate DRI1 support * Fixes for running without DRI at all These code removals represent a deletion of a substantial amount of code, (and hopefully piles of bugs), as well as reduce the maintenance effort going forward as the number of combinatorial configurations for the driver are greatly reduced. This means that users are much more likely to be running code that has actually been tested, and it will be much easy for developers to replicate bugs that users experience. Many thanks to Eric Anholt for gutting so much code! And see Keith Packard's writeup describing the benefits of this code removal: http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/ One of the things that would be most useful in testing this release is to revisit any outstanding bugs that you have previously reported. If the buggy behavior is gone, (or the bug is no longer relevant---such as a bug that's specific to XAA only), please feel free to indicate so in bugzilla or even just close the bug. If you confirm that the bug is still present, please indicate so in the bug report. (I was going to ask that you select a 1.7.99 version, but it looks like bugzilla only has versions for products not compoenents, while we use a xorg product and a driver/intel component.) We definitely want to make any such confirmed bugs a priority, so it would be nice to have a consistent mechanism to search for these bugs. Suggestions are welcome on the best approach. Thanks in advance for any testing or feedback on this snapshot. -Carl Getting the snapshot git tag: 2.7.99.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.99.1.tar.bz2 MD5: ec222b8e617f79c3dee03db71db053a2 xf86-video-intel-2.7.99.1.tar.bz2 SHA1: c8c88d341dd79c4561018c5a279c8f6e66f84089 xf86-video-intel-2.7.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.7.99.1.tar.gz MD5: 797eaa5d8abdabd92bdc261ca1b53634 xf86-video-intel-2.7.99.1.tar.gz SHA1: 5ee985ed22e483ac470cceaa65866a871370b747 xf86-video-intel-2.7.99.1.tar.gz All commits since 2.7.0 --- [Note that many of these commits were already cherry-picked and present in 2.7.0] Alan Coopersmith (1): Fix UXA to build with Sun compilers (use __func__ instead of __FUNCTION__) Albert Damen (2): Non-GEM allocations incorrectly force TILE_NONE (bug 20797) Fix crash with XV with large virtual display Carl Worth (18): Revert the rest of the EXA_VERSION_MAJOR bump Use WAIT_FOR_SCAN_LINE instead of WAIT_FOR_VBLANK Remove support for 'auto'(-1) value of XV_SYNC_TO_VBLANK Fix new video sync-to-blank code for multi-head Don't clip video to CRTC in the case of textured video Add a RELEASING file documenting the release process README: Remove almost all time-sensitive information Add a new AUTHORS file Clarify that the default acceleration is UXA if KMS is available. Add a NEWS files with release-notes for 2.7.0 Add AUTHORS and NEWS to EXTRA_DIST NEWS: Add note about broken PAT code in some kernels RELEASING: Update instructions to reflect some minor process improvements AUTHORS: Add Robert Lowery to the authors file README: Fix typos in chipset list, and point to how_to_report_bug web page RELEASING: Note that --with-xserver-source is needed for make distcheck Increment version to 2.7.99.1 NEWS: Add notes for 2.7.99.1 snapshot Dan Nicholson (1): Fix dist of xvmc sources Eric Anholt (35): Fix XV with non-GEM kernels by allocating a larger fake bufmgr. Add PGETBL_CTL to the debug output. Add dumping of 915 and 945 fence registers. Add DCC register dumping. Move contributed m4 (dolt) to a subdirectory so we can include it with others. Add shave support, enabled by default. Remove some dead i830.h struct members. Rename EXA rendering functions to UXA, since we're keeping them post-EXA. Remove dead mono cursor load code. Remove unused i830_output_type_names Use a static inline to replace if (0) to an unused stub function. Staticize a bunch of functions and variables in the driver. Replace a bunch of #ifdef debug flushing/syncing with a single function. Remove dead monitor detect debugger. Remove dead xoffset/yoffset from pre-randr. Revert fix overflow warning on videoRam Don't try to do anything for I830Sync when VT switched. Fix
Re: 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption
This is realy old issue now. Which I reported at begining of this month but exist much longer. https://bugs.freedesktop.org/show_bug.cgi?id=20896 Two more people also experience this. This only happens with KMS mode. I am using 1.6.1 xorg/mesa master/ xf86-intel master and libdrm 2.4.9 kernel 2.6.30-rc3-git5. I hope someone can soleve this some day. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Old System, New Install Isuue
Magnus Kessler wrote:
On Tuesday 28 April 2009, James Butler wrote:
Hello!
Fedora Core 4 (Linux 2.6.17-1)
yum install xorg-x11 (v.6.8.2)
This is a headless dedicated system with FC4 pre-installed by the
hosting service. It is one of hundreds in a remote rack. I have no
direct access to the system.
I have been running and updating this system using the CLI for about 3
years, however I now need some sort of X system running if I want to run
VisualChat software for my users. Its Java programming requires a
windows manager (X) when run on a Linux box.
Since I had no X installed on this system, I used yum to install it,
seemingly without any issues. All of the dependencies (i.e. xinit) were
successfully installed, as well.
After installing xorg-x11, I ran X -configure to generate a
system-specific config file. I am now stuck with the server failing to
start and generating no error messages that I can act upon.
Executing 'X -config /user/xorg.conf.new', I see this midway through the
Xorg.0.log file:
Xorg.0.log snippet start ==
(II) I810(0): Display Info: CRT: attached: FALSE, present: FALSE, \
size: (0,0)
...
(II) I810(0): Currently active displays on Pipe A:
(II) I810(0):CRT
(==) I810(0): Display is using Pipe A
...
(II) I810(0): Will use BIOS call 0x5f05 to set refresh rates for CRTs.
log end ==
And then this at the end of the log (when everything halts):
Xorg.0.log snippet start ==
...
(WW) I810(0): Successfully set original devices
(WW) I810(0): Setting the original video mode instead of restoring \
the saved state
(WW) I810(0): Extended BIOS function 0x5f05 failed.
(II) I810(0): BIOS call 0x5f05 not supported, setting refresh with \
VBE 3 method.
(II) I810(0): xf86UnbindGARTMemory: unbind key 7
...
{unbind key 0,1,3,2,4,5,6 follow}
...
(WW) I810(0): Successfully set original devices (2)
log end ==
boom. It gets no further.
So a BIOS failure to call 0x5f05 would seem to indicate a problem
getting the (non-existent) monitor to initialize.
Is it possible to run X without an attached monitor, mouse or keyboard?
Shall I post the full Xorg.0.log and my xorg.conf.new file?
I appreciate any guidance.
James
Hi James,
depending on the exact needs of the Java software you want to install you
might be able to do it without an X environment at all.
Have you tried running Java in headless mode (java -Djava.awt.headless=true)
as documented on
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ ? I
presume that you only need a graphical environment during installation and
that the software is later used over the web. Some installers I've seen fall
back to character output when run in headless mode.
HTH,
Magnus
Magnus, headless sounds ideal. Unfortunately, a
java.lang.NoClassDefFoundError gets thrown when I invoke headless with
the current applet. No doubt because the applet is completely unaware of
headless, and would need to be rewritten to use it, at least in parts.
Bummage.
Thank you very much for the suggestion.
James
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
Daniel Stone wrote: Hi, On Tue, Apr 28, 2009 at 10:01:25PM +0100, Phil Endecott wrote: Specifically, when X started I had no keyboard or mouse. After power-cycling [no other way to escape!] I found a message in the log saying that AllowEmptyInput was enabled and that my keyboard and mouse configuration was being ignored. Having looked this up in man xorg.conf I see that this mode is the default. I'll try to be polite: This does not seem like the most useful behaviour. AllowEmptyInput does not mean that your keyboard and mouse configuration is being ignored; conversely, it means that it's not a fatal error to have no keyboard and mouse configuration whatsoever. So if AEI changes anything, you don't have a keyboard and mouse configured. Here is what it reported in the log: (WW) AllowEmptyInput is on, devices usingdrivers 'kbd, 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Generic Keyboard (WW) Disabling Evoluent Vertical Mouse That looks to me as if the default setting of that option causes X to ignore (or disable, if that means something different) my keyboard and mouse. Having set AutoAddDevices to false in order to disable the unhelpful AllowEmptyInput, I now have a functioning mouse. But I have a keyboard where every alternate keystroke produces the right letter and the others produce garbage (maybe top-bit-set characters?). Cool. Could you please send xev output? Unfortunately this is hard as I cannot log in. Presumably there is some way in which I can bypass xdm and cause X to start running and then start xev from another machine, or something. I'll investigate. Looking at this some more, here is what I think is happening. This is based on what I type at the xdm username: prompt. Characters are alternately normal and sent with Ctrl. So e.g. h is backspace, j shows a glyph with a V above a T for vertical tab, etc. I also get box-drawing characters for some letters. I also noticed some messages in the log where config/hal complained that NewInputDeviceRequest failed. Presumably this is because of my AutoAddDevices. I had noticed that Debian installed hal; I had not previously heard of it. It looks like something that sits on top of udev. Yes, it is. NewInputDeviceRequest failing sounds like the evdev driver isn't installed. evdev was listed in the Modules section (I had been using it previously for the Powermate) and I don't recall any problems with it mentioned in the log. BTW, attaching complete logs instead of two-word snippets often leads to significantly more happiness. I would love to copy-and-paste the logs but I am sending this from another computer. The bit above was re-typed. So I've now spent most of three days on this. I just want a computer that works, preferably as well as the old one did, and while I don't have one I can't do much work [I'm self-employed]. So could someone please suggest what I should do: - Is there some simple set of xorg.conf settings that will make it just work like it did before, without any AllowEmptyInput and HAL stuff and with a functional keyboard? The Debian guys can explain that much better than me. - Or would I be better off trying to learn how this HAL thing works? X is something that I only have to understand once every few years when I have some new hardware. By the next time I need to understand it, either I have forgotten something vital or it has all changed Well, not upgrading guarantees there won't be any changes. :) I would have loved to not upgrade. There was nothing wrong with the old system until it broke. Paul Menzel suggests that I should be able to run with no Xorg.conf. When I try this I still get the bizarre keyboard behaviour. The Debian package versions are: xserver-xorg 7.4+1 xserver-xorg-core 1.6.1-1 xserver-xorg-input-evdev 2.2.1-1 xserver-xorg-input-kbd 1.3.2-3 xserver-input-mouse 1.4.0-2 xserver-xorg-input-synaptics 1.1.0-1 xserver-xorg-input-wacom 0.8.3.2-1 xserver-xorg-video-openchrome 0.2.903+svn741-1+b1 Regards, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 2.6.30-rc2 + xorg-intel-2.7.0 + DRM_I915_KMS = corruption
This is fixed with Kernel 2.6.30-rc3-git6 for me, so you might try this one. bye Andreas On Wed, 2009-04-29 at 20:18 +0200, Mateusz Kaduk wrote: This is realy old issue now. Which I reported at begining of this month but exist much longer. https://bugs.freedesktop.org/show_bug.cgi?id=20896 Two more people also experience this. This only happens with KMS mode. I am using 1.6.1 xorg/mesa master/ xf86-intel master and libdrm 2.4.9 kernel 2.6.30-rc3-git5. I hope someone can soleve this some day. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Andreas Proschofsky Gentoo Developer / OpenOffice.org 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: AllowEmptyInput and HAL
On Wed, 2009-04-29 at 19:32 +0100, Phil Endecott wrote: Daniel Stone wrote: AllowEmptyInput does not mean that your keyboard and mouse configuration is being ignored; conversely, it means that it's not a fatal error to have no keyboard and mouse configuration whatsoever. So if AEI changes anything, you don't have a keyboard and mouse configured. Here is what it reported in the log: Hi Phil, I don't know if it's exactly the same as your situation, but I recently had a situation with X on Debian acting up and resulting in mismapped keys. The log file in that case showed that the mouse driver was getting loaded. But clearly something was misinterpreting events. Perhaps something was expecting events as they would come from evdev instead? I don't know. The fix for my situation was to ensure that the evdev module was loaded instead of the mouse module. I could have made that happen by editing xorg.conf, but I'm told that that's passé now. Instead I copied the attached x11-input.fdi file, (which I got from a friend), to /etc/hal/fdi/policy. After doing this, hal loaded the evdev module for me and everything became happy. This didn't quite feel to me like the happy no-configuration-required-for-X paradise I had been promised, but there you have it. :-) I've been led to understand that this is due to a bug in the Debian packaging of hal. But I don't really know if the blame lies with upstream HAL, with Debian packaging, or even something else in the X server that made things not work. All I know is that this is what fixed things for me. So I thought I would pass it on in case it helps you as well. -Carl x11-input.fdi Description: XML document 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: Detecting the used keyboard driver
On Tue, Apr 28, 2009 at 11:10:57AM +0200, Marvin Raaijmakers wrote: Well I developed keyTouch, a program that allows the user to bind actions to extra function keys (like the Play/Pause, WWW or Zoom keys for example) on a keyboard. KeyTouch is a collection of programs. One program binds a key's scancode to a Linux keycode. So it changes the mapping inside the Linux kernel. Another program is an X client and grabs all key events of the extra function keys. So this program needs to know the X keycodes of the keys and thus it will have to translate the kernel keycode to the X keycode. These translations are different when the evdev input driver is used by the X server instead of the kbd driver. This sounds like the wrong way to do it. Why not just ensure that the keymap contains the correct keycode-keysym mappings in the first place? -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
Phil Endecott wrote: Daniel Stone wrote: Hi, On Tue, Apr 28, 2009 at 10:01:25PM +0100, Phil Endecott wrote: I have a keyboard where every alternate keystroke produces the right letter and the others produce garbage (maybe top-bit-set characters?). Cool. Could you please send xev output? Unfortunately this is hard as I cannot log in. Presumably there is some way in which I can bypass xdm and cause X to start running and then start xev from another machine, or something. I'll investigate. I started x using startx and I can now retype the following xev output. This is for press-release-press-release of the A key. The pattern then repeats and seems to be consistent with other keys: KeyPress event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372197, (78,77), root:(699,464), state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 bytes: (01) XmbLookupString gives 1 bytes: (01) XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372293, (78,77), root:(699,464), state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 bytes: (01) KeyPress event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372549, (78,77), root:(699,464), state 0x0, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) a XmbLookupString gives 1 bytes: (61) a XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372621, (78,77), root:(699,464), state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 bytes: (01) I then ran strace on X and looked at what it read from /dev/input/event1 while I did the same thing. Deciphering using /usr/include/linux/input.h I see MSC SCAN 0407 KEY A DOWN SYN MSC SCAN 0407 KEY A UP SYN MSC SCAN 0407 KEY A DOWN SYN MSC SCAN 0407 KEY A UP SYN i.e. nothing unusual (I haven't seen the 'scan' stuff before, but I presume that X has done an ioctl to ask for it or something.) Perhaps these events are being misinterpretted in the wrong format, or something. But in that case I would have expected the symptom to be recognised by someone. Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
On Wed, 2009-04-29 at 13:18 -0700, Carl Worth wrote: On Wed, 2009-04-29 at 19:32 +0100, Phil Endecott wrote: Daniel Stone wrote: AllowEmptyInput does not mean that your keyboard and mouse configuration is being ignored; conversely, it means that it's not a fatal error to have no keyboard and mouse configuration whatsoever. So if AEI changes anything, you don't have a keyboard and mouse configured. Just to be clear... AllowEmptyInput does claim that statically configured devices will be disabled. (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Mouse0 (WW) Disabling Keyboard0 robert. Here is what it reported in the log: Hi Phil, I don't know if it's exactly the same as your situation, but I recently had a situation with X on Debian acting up and resulting in mismapped keys. The log file in that case showed that the mouse driver was getting loaded. But clearly something was misinterpreting events. Perhaps something was expecting events as they would come from evdev instead? I don't know. The fix for my situation was to ensure that the evdev module was loaded instead of the mouse module. I could have made that happen by editing xorg.conf, but I'm told that that's passé now. Instead I copied the attached x11-input.fdi file, (which I got from a friend), to /etc/hal/fdi/policy. After doing this, hal loaded the evdev module for me and everything became happy. This didn't quite feel to me like the happy no-configuration-required-for-X paradise I had been promised, but there you have it. :-) I've been led to understand that this is due to a bug in the Debian packaging of hal. But I don't really know if the blame lies with upstream HAL, with Debian packaging, or even something else in the X server that made things not work. All I know is that this is what fixed things for me. So I thought I would pass it on in case it helps you as well. -Carl ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Robert Noland rnol...@2hip.net 2Hip Networks 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: Griffin Powermate evdev setup
On Wed, Apr 29, 2009 at 06:56:47AM -0500, David Hagood wrote: I'd like to ask a more general question about devices which, like the Powermate, don't really fit into either the Keyboard or Pointing device classes: To what extent *should* X support these devices? Let's examine a ShuttlePro - a jog wheel, a spinner, 15 buttons. It's not really a keyboard, as the buttons don't really have any defined mapping other than Button 1 ... Button 15. It's not a pointing device. Applications like Kino recognize it and can use it to do editing control, in which case the jog wheel and the spinner are logically distinct from the mouse's wheel. Kino supports this device by going directly to the underlying /dev/input/event device, and not through X. Now, that works - and perhaps that is how it should be: X concerns itself with pointers and keyboards, and we let other things be handled outside of X. HOWEVER, that approach has several problems: 1) No remote access: I cannot run a program on another machine and have it use the Shuttle unless the Shuttle is supported by X. 2) No arbitration between applications: If Kino and some other program Foo both understand the Shuttle and want to use it, and I change input focus from Kino to Foo, how do we route the events correctly? Do the programs close the device when the lose input focus, and re-open it when the regain focus? Do they ignore events when not focused? 3) Less portable code - going to /dev/input/event5 may be fine under Linux, but is it supported under the *BSD kernels? under the Mac's X server? under Solaris/Irix/AIX? You can generalize this to things like joysticks and game pads - as far as I can see, there is little difference between a Shuttle and my PS3 DualShock as far as things like this go. Has there been a design decision where support for devices like this should live? evdev already does axis and button labelling, and that is built into XI2 so that the server enforces it to some extent (still needs help by the driver of course). So if you have a device that only has REL_X, REL_Y, BTN_LEFT, BTN_BANANA, the driver labels it accordingly and you can query this information by reading the matching properties. All the client needs to do then is to map the buttons/axes to the functionality as desired. There's room for a global configuration in the desktop environment (e.g. make REL_DIAL always map to scroll) but that's not really up for X to decide. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-mach64 6.8.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aaron Plattner (1):
Make sure the screen is a mach64 screen before doing anything in
ATIMach64XVInitialiseAdaptor.
Adam Jackson (1):
Don't print the resource list on failure.
Alan Coopersmith (3):
Add README with pointers to mailing list, bugzilla git repos
Convert to XORG_CWARNFLAGS XORG_CHANGELOG
Version 6.8.1
Paulo Cesar Pereira de Andrade (1):
Remove xf86{Disable,Enable}Interrupts
git tag: xf86-video-mach64-6.8.1
http://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.8.1.tar.bz2
MD5: 0856d9c8435cf4350b68fbd57ca6d4fc
SHA1: b5a811372e8624eeb3c53b8a53eecf24eec88420
http://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.8.1.tar.gz
MD5: 4893de8d172d81e3d269e15d6b4c24d5
SHA1: 5f1f7cda9a17c9d1cddbca38db6631ca1e1e6878
- --
-Alan Coopersmith- alan.coopersm...@sun.com
Sun Microsystems, Inc. - X Window System Engineering
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (SunOS)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkn4+swACgkQovueCB8tEw4cMACfd/a2UO8/J2WmfoTUpNdeVyWR
NdoAnjHg2okJyjiGxqUqW6xrREB7xO8X
=flGN
-END PGP SIGNATURE-
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
On Thu, Apr 30, 2009 at 10:59:50 +1000, Peter Hutterer wrote: unless I overlooked something, this fdi file is the standard one that should be installed as part of either the hal package or the X server package (fedora installs it as part of hal). So in your case it does indeed look like a distribution packaging error. On Debian, the xserver-xorg package installs an fdi and a callout to set the xkb keys, and the evdev, synaptics and vmmouse driver packages each install an fdi for the devices they handle. That shouldn't make any practical difference to how things work in Fedora, as far as I know. So if people are having problems with this on current unstable, debia...@lists.debian.org would love to hear about them (bonus points if you include the full X log, though). :) Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
