Re: kernel 2.6.27 and git xorg stuff
On Fri, May 01, 2009 at 08:38:46AM +0200, Werner LEMBERG wrote: > Slightly off-topic: Regarding a new kernel, I wonder whether there is > a tool which helps in updating the kernel config file to the new > version. Normally, zillions of kernel options either change its name, > appear, or disappear, making it very hard for normal users to find the > right configuration. 'make oldconfig' > More off-topic, which would make my life *much* easier and saving me > from the hassles mentioned in the previous paragraph: Is someone > providing recent Linux kernels for openSuSE 11.1? :-) We are providing recent Linux kernels for opensuse in the opensuse build system, and in the FACTORY branch for opensuse. Hope this helps, greg k-h ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
kernel 2.6.27 and git xorg stuff
Folks, it seems that X development is tightly bound to bleeding-edge releases of the Linux kernel. I still have a 2.6.27.21 kernel on my machine, and I want to know whether I really have to update my kernel to test the xserver and, in particular, the intel graphics driver. For example, I've seen in the intel announcement that they only support UXA now. But, AFAIK, this needs support from a kernel > 2.6.27. Is this correct? BTW, what's the general policy w.r.t. to older kernels? I can imagine that many people would like to have a more recent X system (for example, better 3D support for certain graphics cards) without having to update the rest of the system... Slightly off-topic: Regarding a new kernel, I wonder whether there is a tool which helps in updating the kernel config file to the new version. Normally, zillions of kernel options either change its name, appear, or disappear, making it very hard for normal users to find the right configuration. More off-topic, which would make my life *much* easier and saving me from the hassles mentioned in the previous paragraph: Is someone providing recent Linux kernels for openSuSE 11.1? :-) Werner ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Detecting the used keyboard driver
On Thu, Apr 30, 2009 at 07:20:13PM +0100, Matthew Garrett wrote: > On Thu, Apr 30, 2009 at 08:09:01PM +0200, Marvin Raaijmakers wrote: > > Well a scancode is for the kernel like what a X keycode is to the X > > server, and a kernel keycode is for the kernel what a key symbol is to > > the X server. So when you change the kernel keycode of a key, then the > > X server will receive another kernel keycode from the kernel and as a > > result the key will have another X keycode. So an X keycode is not > > fixed for a specific key. Furthermore some keys will not have a kernel > > keycode by default and such keys won't work under X (because the X > > server doesn't receive anything about these keys from the kernel). > > Believe me I've thought about this ;) > > For a given kernel keycode and a given X keyboard driver, the X keycode > will always be the same. If you're setting the scancode to the canonical > kernel keycode that'll be a meaningful transformation. So you could just > add those X keycodes to the pc105 keymap, since they're already present > in the evdev keymap and so will already produce the correct keysyms with > the evdev driver. For example: > > Scancode e007 will be the battery key scancode on a Dell. This will map > to kernel keycode 236 (KEY_BATTERY). kbd will read this as e044 and > translate it into X keycode 204. evdev will read this as 236 and (I > /think/ - I can't remember if the +8 mapping is still relevant for > evdev) translate it into X keycode 244. it is still relevant. The min_keycode 8 is a requirement of the core protocol, so we just add 8 to all keycodes. > As long as the kernel keycode is KEY_BATTERY, the X keycode will depend > only on whether kbd or evdev is in use. evdev will always use the evdev > keymap and that already maps all of the Linux keycodes to appropriate X > keysyms. The keymap typically used for the old driver is pc105, and I > suspect that it doesn't have these mappings. They'd be easy to add and > it's the appropriate place to put them. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
MGA driver support of dual-head
I've lost dual-head since we, FreeBSD, switched from XFree86 to x.org. I understand that randr is superceding Xinerama, right? So my question is, will dual-head support in the mga driver be forthcoming, or do I need to switch to another card? I've searched the archives and this question has been left unanswered. Is there a page on x.org that details their development plans, such as whether they have plans to fix mga or drop it? xrandr-1.3.0 doesn't appear to recognize the second port on the Matrox G550. -- Steven Friedrich Lexington, KY 40509 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Detecting the used keyboard driver
On Thu, Apr 30, 2009 at 08:09:01PM +0200, Marvin Raaijmakers wrote: > Well a scancode is for the kernel like what a X keycode is to the X > server, and a kernel keycode is for the kernel what a key symbol is to > the X server. So when you change the kernel keycode of a key, then the > X server will receive another kernel keycode from the kernel and as a > result the key will have another X keycode. So an X keycode is not > fixed for a specific key. Furthermore some keys will not have a kernel > keycode by default and such keys won't work under X (because the X > server doesn't receive anything about these keys from the kernel). > Believe me I've thought about this ;) For a given kernel keycode and a given X keyboard driver, the X keycode will always be the same. If you're setting the scancode to the canonical kernel keycode that'll be a meaningful transformation. So you could just add those X keycodes to the pc105 keymap, since they're already present in the evdev keymap and so will already produce the correct keysyms with the evdev driver. For example: Scancode e007 will be the battery key scancode on a Dell. This will map to kernel keycode 236 (KEY_BATTERY). kbd will read this as e044 and translate it into X keycode 204. evdev will read this as 236 and (I /think/ - I can't remember if the +8 mapping is still relevant for evdev) translate it into X keycode 244. As long as the kernel keycode is KEY_BATTERY, the X keycode will depend only on whether kbd or evdev is in use. evdev will always use the evdev keymap and that already maps all of the Linux keycodes to appropriate X keysyms. The keymap typically used for the old driver is pc105, and I suspect that it doesn't have these mappings. They'd be easy to add and it's the appropriate place to put them. -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Detecting the used keyboard driver
Well a scancode is for the kernel like what a X keycode is to the X server, and a kernel keycode is for the kernel what a key symbol is to the X server. So when you change the kernel keycode of a key, then the X server will receive another kernel keycode from the kernel and as a result the key will have another X keycode. So an X keycode is not fixed for a specific key. Furthermore some keys will not have a kernel keycode by default and such keys won't work under X (because the X server doesn't receive anything about these keys from the kernel). Believe me I've thought about this ;) - Marvin On Wed, Apr 29, 2009 at 10:26 PM, Matthew Garrett 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 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 > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] intel-gpu-tools 1.0
2009/4/27 Eric Anholt : > This little package is an amalgamation of a few things: > - miscellaneous userland tools that don't really fit into the 2D driver tree > - standalone regression tests for the DRM (make check) Interesting. My run reported 1 failure but make check is quite verbose so it was hard to tell which. However there was a core in the directory: 15:27 a...@danny/x86_64 [tests] >ls Makefile gem_basicgem_flink.c gem_mmap.o gem_readwritegem_ringfill.c gem_tiled_blits.o getclient getstats.cgetversion.o Makefile.am gem_basic.c gem_flink.o gem_pread_after_blit gem_readwrite.c gem_ringfill.o gem_tiled_preadgetclient.c getstats.o Makefile.in gem_basic.o gem_mmap gem_pread_after_blit.c gem_readwrite.o gem_tiled_blitsgem_tiled_pread.c getclient.o getversion core gem_flinkgem_mmap.c gem_pread_after_blit.o gem_ringfill gem_tiled_blits.c gem_tiled_pread.o getstats getversion.c 15:27 a...@danny/x86_64 [tests] >file core core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './gem_tiled_pread' 15:28 a...@danny/x86_64 [tests] >./gem_tiled_pread bo_gem: 0x20a62f0 bucket: 0x20a50f0 bo_gem: 0x20a6450 bucket: 0x20a51b0 Bad read: 528 instead of 512 at 0x0200 for read from 0x to 0x0010 Aborted (core dumped) Of course it may be wedged as X has been up and down while I've been generating bug traces for Jesse: https://bugs.freedesktop.org/show_bug.cgi?id=21480 However it caught my eye as the crash in libdrm there was due to a bad pointer somewhere between bo_gem and bucket. I assume the kernel side should be resilient to user space crashes though? -- Alex, homepage: http://www.bennee.com/~alex/ CV: http://www.bennee.com/~alex/cv.php ___ 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!)
On Wednesday 29 April 2009 05:49:31 Carl Worth wrote: > 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. I tried this snapshot with KMS/DRI2 on GM965, kernel 2.6.30-rc4, xserver 1.6.1, mesa 7.4, libdrm 2.4.9. Redirecting output on VGA now seems to work, so I am closing bug #21250. With 2.7.0, I was also seing some corruption similar to that of bug #21415, especially after a couple of resume from STD. With 2.7.99.1 and after 3-4 resumes, there is no corruption at all. Maybe reporters of that bug may try the latest snapshot as well... Thanks, Stefano > > 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 > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with KMS
Hi, > Then I tried 2.7.0: Without KMS I got a blank screen when x started. > With KMS I got very havy display errors. (Turning the display into > something pink-i-can-barly-see-that-it's-kdm) Very likely to be related to http://bugs.freedesktop.org/show_bug.cgi?id=21246 which is a kernel bug. You can patch your kernel with http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=f544847fbaf099278343f875987a983f2b913134 or use latest git from Linus branch where the patch has been applied (happened somewhere between 2.6.30-rc3 et 2.6.30-rc3-git6) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Problems with KMS
Hi, i'm using Gentoo with Kernel 2.6.29 and xorg-server 1.5.3 Yesterday I've start trying KMS. This are my results: When enabled I always got a nice framebuffer console in my native resolution. (adding i915.modeset=1 as a kernel parameter) When in use with intel driver 2.6.3 my kde had a wrong (lower) resolution. I think it was like 1024 for my 1440 screen or so. This of course caused the screen to flicker when switching from framebuffer console to KDM. When I started KDE it crashed the xserver (freezed) as soon as the loading screen from kde was at 100%. When I started the secure mode in KDM (only a xterm) I could set the native resolution with xrandr to 1440px. Then I got display errors (The 1024px screen was repated to the left and the bottom) BUT i could switch from framebuffer to Xorg without flicker: YEAH! Then I tried 2.7.0: Without KMS I got a blank screen when x started. With KMS I got very havy display errors. (Turning the display into something pink-i-can-barly-see-that-it's-kdm) - Daniel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
