Re: How To Disable input driver
On Wednesday 11 February 2009, Peter Hutterer wrote: On Wed, Feb 11, 2009 at 08:37:44PM +, Magnus Kessler wrote: On Wednesday 11 February 2009, linux multitouch wrote: Hi I am using Xorg version - 1.5.2 I am developing kernel driver which create /dev/eventX - file. when i insert the kernel driver X11 thinks it's a mouse. how can i configure the X11 to ignore the driver (/dev/eventX) thanks Assuming your Xorg server is configured via hal, you can place a file in /etc/hal/fdi/policy/ that removes the driver key. I use the following file to suppress a joystick from being recognized as an X11 input device: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input !-- Match on anything you like from lshal -- match key=input.product contains=SomeProduct Identifier remove key=info.capabilities/ remove key=input.x11_driver/ /match /match /device /deviceinfo Similarly you could use an fdi file to instruct Xorg to use your own input driver. Have a look at the fdi files provided for e.g. synaptics touchpads. Actually, just removing input.x11_driver alone is enough, it's the only thing we really care about in the server. Cheers, Peter Indeed, just removing the input driver key is enough. The line about the capabilities was a left-over from trying to have the joystick NOT recognized as a mouse in the first place. A previous version read something like: remove key=info.capabilities/ merge key=info.capabilities type=strlistinput.joystick/merge merge key=input.x11_driver type=stringjoystick/merge If memory serves correctly without the capabilities lines the joystick driver would not work correctly, as it was getting confused by the buttons. But this was some time ago and I haven't played with the settings recently. Cheeers, Magnus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xvesa black magic
Hi, On 12.02.2009, at 08:23, William Tracy wrote: Also, for completeness, not that I expect it to be helpful: # Xvesa -mode 0x117 -kb -mouse mouse,/dev/input/mice -keybd keyboard Int 10h (0x4F10) failed: 0x014F (function call failed) No DPMS Support -1 FreeFontPath: FPE build-ins refcount is 2, should be 1; fixing. Sorry, resurrecting a GL-less kdrive build on the last release xorg-server was eating my time, and it's still not there. Even more annoying is that the kdrive xvesa was deleted from the xorg-server git repository some weeks ago! http://cgit.freedesktop.org/xorg/xserver/commit/?id=6d21fbf00648307208146aca0837ec63ea490659 Too bad the commit message does not even indicate why, ... -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xvesa black magic
Le 12/02/2009 09:38, Rene Rebe a écrit : Even more annoying is that the kdrive xvesa was deleted from the xorg-server git repository some weeks ago! http://cgit.freedesktop.org/xorg/xserver/commit/?id=6d21fbf00648307208146aca0837ec63ea490659 Too bad the commit message does not even indicate why, ... Because it had been severely broken by other changes in the server and no-one really cared about it anyway. You'll probably be much better off using kdrive's Xfbdev on top of uvesafb or another kernel fb driver. Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel memory leakage
On Monday 09 February 2009 20:28:14 Johannes Engel wrote: Jesse Barnes wrote: Interesting, thanks for trying to narrow it down. I don't see anything on re-review that would cause huge increases in the amount of memory used, though the additional alignment we apply in that patch will increase things somewhat, so might make the problem happen faster. Are you using UXA or EXA? You are probably right here, Jesse: Letting Xorg run with UXA on my GM945 turns out to show a similar problem after a couple of hours or similar. sudo lsof | grep drm mm object | wc -l shows the incredible number of 2407... I have a different issue, but I would also call it a memory leakage. I am on GM965 using KDE4 with DRI2. I tried both with debian experimental packages (xserver 1.5.99.901, mesa 7.3, libdrm 2.4.4+git+20090205) and with self- compiled stack from git master as of yesterday. The kernel is from airlied's drm-fixes branch up to commit d2f59357700487a8b944f4fd1e97cf5ea2ed (drm/i915: select framebuffer support automatically). After a fresh boot and login into KDE4, top shows that Xorg uses 2.1% of memory (2 GB). Attached is what xrestop shows (xrestop_2.1_568020k, where 568020k is the total memory usage as shown by top). Then, I launch some applications and, after a couple of hours, close all of them and top shows that Xorg now uses 18.1% of memory. Attached is also what xrestop shows now. It looks like that closing a KDE application does not free memory used by Xorg (as shown by top). Also, switching between applications (especially using composite effects like present windows) causes an increase in the memory usage of Xorg. I have to say that I have another machine with a similar setup (except the kernel which is a 2.6.26 kernel) with an ATI card (using radeon driver) that does not show such behavior. Also, when I resume from a suspend to disk, top shows that some swap memory is used (while before suspending the swap memory was not used), e.g., 791604k. The swap memory used seems to increase after subsequent suspend/resume cycles. If matters, sudo lsof | grep drm mm object | wc -l reports 9944... Any hint how to debug further and provide more information? thanks, Stefano ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel memory leakage
On Thursday 12 February 2009 10:26:14 Stefano Avallone wrote: On Monday 09 February 2009 20:28:14 Johannes Engel wrote: Jesse Barnes wrote: Interesting, thanks for trying to narrow it down. I don't see anything on re-review that would cause huge increases in the amount of memory used, though the additional alignment we apply in that patch will increase things somewhat, so might make the problem happen faster. Are you using UXA or EXA? You are probably right here, Jesse: Letting Xorg run with UXA on my GM945 turns out to show a similar problem after a couple of hours or similar. sudo lsof | grep drm mm object | wc -l shows the incredible number of 2407... I have a different issue, but I would also call it a memory leakage. I am on GM965 using KDE4 with DRI2. I tried both with debian experimental packages (xserver 1.5.99.901, mesa 7.3, libdrm 2.4.4+git+20090205) and with self- compiled stack from git master as of yesterday. The kernel is from airlied's drm-fixes branch up to commit d2f59357700487a8b944f4fd1e97cf5ea2ed (drm/i915: select framebuffer support automatically). After a fresh boot and login into KDE4, top shows that Xorg uses 2.1% of memory (2 GB). Attached is what xrestop shows (xrestop_2.1_568020k, where 568020k is the total memory usage as shown by top). Then, I launch some applications and, after a couple of hours, close all of them and top shows that Xorg now uses 18.1% of memory. Attached is also what xrestop shows now. It looks like that closing a KDE application does not free memory used by Xorg (as shown by top). Also, switching between applications (especially using composite effects like present windows) causes an increase in the memory usage of Xorg. I have to say that I have another machine with a similar setup (except the kernel which is a 2.6.26 kernel) with an ATI card (using radeon driver) that does not show such behavior. Also, when I resume from a suspend to disk, top shows that some swap memory is used (while before suspending the swap memory was not used), e.g., 791604k. The swap memory used seems to increase after subsequent suspend/resume cycles. If matters, sudo lsof | grep drm mm object | wc -l reports 9944... Any hint how to debug further and provide more information? thanks, Stefano forgot the attachments, sorry :-) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg 0 - Qt-subapplication ( PID: 6862 ): pixmap bytes : 13189150 other bytes : ~10984 total bytes : ~13200134 1 - unknown ( PID: ? ): pixmap bytes : 4096000 other bytes : ~4544 total bytes : ~4100544 2 - KWin ( PID: 6855 ): pixmap bytes : 1933362 other bytes : ~4264 total bytes : ~1937626 3 - Yakuake ( PID: 6900 ): pixmap bytes : 1366934 other bytes : ~2392 total bytes : ~1369326 4 - unknown ( PID: ? ): pixmap bytes : 207920 other bytes : ~6520 total bytes : ~214440 5 - unknown ( PID: ? ): pixmap bytes : 173912 other bytes : ~2056 total bytes : ~175968 6 - klipper ( PID: 6907 ): pixmap bytes : 127720 other bytes : ~1792 total bytes : ~129512 7 - kmix ( PID: 6905 ): pixmap bytes : 109032 other bytes : ~1840 total bytes : ~110872 8 - kwalletmanager ( PID: 6967 ): pixmap bytes : 73528 other bytes : ~1624 total bytes : ~75152 9 - korgac ( PID: 6911 ): pixmap bytes : 30384 other bytes
Re: Xvesa black magic
On 12.02.2009, at 09:59, Rémi Cardona wrote: Le 12/02/2009 09:38, Rene Rebe a écrit : Even more annoying is that the kdrive xvesa was deleted from the xorg-server git repository some weeks ago! http://cgit.freedesktop.org/xorg/xserver/commit/?id=6d21fbf00648307208146aca0837ec63ea490659 Too bad the commit message does not even indicate why, ... Because it had been severely broken by other changes in the server and no-one really cared about it anyway. You'll probably be much better off using kdrive's Xfbdev on top of uvesafb or another kernel fb driver. The random regressions and feature removal in the open source world these days really make one wonder. -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] xf86-video-intel memory leakage
On Thu, 2009-02-12 at 10:26 +0100, Stefano Avallone wrote: On Monday 09 February 2009 20:28:14 Johannes Engel wrote: Jesse Barnes wrote: Interesting, thanks for trying to narrow it down. I don't see anything on re-review that would cause huge increases in the amount of memory used, though the additional alignment we apply in that patch will increase things somewhat, so might make the problem happen faster. Are you using UXA or EXA? You are probably right here, Jesse: Letting Xorg run with UXA on my GM945 turns out to show a similar problem after a couple of hours or similar. sudo lsof | grep drm mm object | wc -l shows the incredible number of 2407... Since cairo-perf will cause a leak of a couple of GiB in a few seconds on my i915, I was able to track down the cause pretty quickly. It turns out not to be limited to uxa at all, just uxa exercises the bufmgr much more than exa. The issue appears to be the bufmgr cache handling which appears unbounded. Its use was introduced with: commit a893f176dda0b64f7dadfda6bf0331240037851e Author: Carl Worth cwo...@cworth.org Date: Fri Jul 25 15:56:35 2008 -0700 Add call to intel_bufmgr_gem_enable_reuse So you can try reverting that commit and confirming if that clears the issue for you. Longer term, I think the buffer cache should be moved into the kernel, as when using client-side rendering we may end up with a bo cache per application. Moving it to the kernel should allow the cache to be shared and for it to reaped in low memory conditions. AIUI, we need to cache bo in order to reduce the cost associated with creating a new shmem object, mapping the page lists and to minimise clflush. The easiest approach would seem to be to add a dev_priv-cache_list and a new create ioctl that took interested domains and returned the current ones for the new object. (One of the improvements I found in cache usage was in relaxing the busy condition for buffers which I knew would only be used for GPU writes and so would be serialised by the batch scheduling.) Suggestions? Ideas? Patches? -ickle ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
same problem
I have the same problem, I use xkeyboard-config-1.5, 1.4, 1.2; xserver 1.5.3; and xkbcomp from git, and I can't solve this problem about one week =((( ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XKB - xkbcomp can't find keycode includes (Bug?)
I have the same problem, I use xkeyboard-config-1.5, 1.4, 1.2; xserver 1.5.3; and xkbcomp from git, and I can't solve this problem about one week =((( ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xvesa black magic
Rene Rebe a écrit : The random regressions and feature removal in the open source world these days really make one wonder. As far as Xvesa is concerned, it's hardly random at all. It's a pile of code that did the same job as the kernel's frame buffer infrastructure. Even regular Xorg has been going that way too with GEM and KMS. Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XKB - xkbcomp can't find keycode includes (Bug?)
On Wed, Feb 11, 2009 at 10:52:21AM +0100, Jacek Luczak wrote:
Hi All,
xkbcomp fail with message:
The XKEYBOARD keymap compiler (xkbcomp) reports:
Error:Can't find file xfree86 for keycodes include
Exiting
Abandoning keycodes file default
Errors from xkbcomp are not fatal to the X server
(EE) Error compiling keymap (server-0)
(EE) XKB: Couldn't compile keymap
The question is, does it look for those includes in directory specified with
--with-xkb-path?
check include/xkb-config.h. does it say the right path there?
does config.log show your settings?
I've got xkeyboard-config (ver. 1.5) build with --with-xkb-base set to
/etc/X11/xkb and --with-xkb-path (Xorg-server 1.5.99.902) also set to same
directory. I was trying to use setxkbmap (build with
--with-xkb-config-root=/etc/X11/xkb) but this didn't work. Finally I've
managed
to fix (or workaround) that issue by creating symlink /usr/share/X11/xkb -
/etc/X11/xkb - {datadir}/X11/xkb is mentioned as default for --with-xkb-patch
xorg-server configure option. So does this option work? Maybe it's responsible
for sth different or this is a bug.
--with-xkb-patch or with-xkb-path (just making sure there's no typo)
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XKB - xkbcomp can't find keycode includes (Bug?)
can you try build xkeyboard-config with --with-xkb-rules-symlink=xorg i had the same problem and this works now. i have build xkeyboard-config with: XKBCOMP=/usr/bin/xkbcomp \ ./configure --host=$TARGET_NAME \ --build=$HOST_NAME \ --prefix=/usr \ --sysconfdir=/etc \ --disable-static \ --enable-shared \ --enable-compat-rules \ --with-xkb-base=$XORG_PATH_XKB \ --disable-xkbcomp-symlink \ --with-xkb-rules-symlink=xorg stephan Zitat von Kolya koly...@mail.ru: I have the same problem, I use xkeyboard-config-1.5, 1.4, 1.2; xserver 1.5.3; and xkbcomp from git, and I can't solve this problem about one week =((( ___ 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: Xvesa black magic
On Thu, Feb 12, 2009 at 10:32:57AM +0100, Rene Rebe wrote: On 12.02.2009, at 09:59, Rémi Cardona wrote: Le 12/02/2009 09:38, Rene Rebe a écrit : Even more annoying is that the kdrive xvesa was deleted from the xorg-server git repository some weeks ago! http://cgit.freedesktop.org/xorg/xserver/commit/?id=6d21fbf00648307208146aca0837ec63ea490659 Too bad the commit message does not even indicate why, ... Because it had been severely broken by other changes in the server and no-one really cared about it anyway. You'll probably be much better off using kdrive's Xfbdev on top of uvesafb or another kernel fb driver. The random regressions and feature removal in the open source world these days really make one wonder. Is there any particular reason why you can't use the Xorg server with evdev for input (hell, kbd/mouse if you like pain) and the vesa or fbdev driver? Removing KDrive wasn't random at all. The size benefit was tiny compared to a pruned Xorg installation (e.g. removing XAA, the I2C TV encoder modules, etc), so there was no use keeping it around. Cheers, Daniel, who was the KDrive maintainer and is happy with it being removed signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] xf86-video-intel memory leakage
Chris Wilson wrote: Since cairo-perf will cause a leak of a couple of GiB in a few seconds on my i915, I was able to track down the cause pretty quickly. It turns out not to be limited to uxa at all, just uxa exercises the bufmgr much more than exa. The issue appears to be the bufmgr cache handling which appears unbounded. Its use was introduced with: commit a893f176dda0b64f7dadfda6bf0331240037851e Author: Carl Worth cwo...@cworth.org Date: Fri Jul 25 15:56:35 2008 -0700 Add call to intel_bufmgr_gem_enable_reuse So you can try reverting that commit and confirming if that clears the issue for you. I am sorry, Chris, but that does not make it any better for me. :( The real issue seems to be another one... Cheers, Johannes ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xorg-x11-drv-ati for Fedora 10 fails to setup DRI for 3520x1600x32 screen, is this normal?
I am checking out what happens when I disable kernel modesetting for a radeon chipset (Xpress 200M RC410) with the xorg-x11-drv-ati package from updates-testing in Fedora 10. So far I have seen that the driver refuses to enable DRI support, as it claims that 64Mb is not enough memory. I added a patch to the source RPM to check what is happening, and I get this on the logs: (II) RADEON(0): RADEONInitMemoryMap() : (II) RADEON(0): mem_size : 0x0400 (II) RADEON(0): MC_FB_LOCATION : 0x3fff3c00 (II) RADEON(0): MC_AGP_LOCATION : 0xffc0 (II) RADEON(0): Depth moves disabled by default (==) RADEON(0): Using accelerated EXA DownloadFromScreen hook (II) RADEON(0): Allocating from a screen of 65536 kb (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x0157c000 (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x0158 (II) RADEON(0): Will use 22000 kb for front buffer at offset 0x (II) RADEON(0): Will use 22000 kb for back buffer at offset 0x01584000 (II) RADEON(0): Will use 10624 kb for textures at offset 0x02b0 (II) RADEON(0): Will use 10880 kb for X Server offscreen at offset 0x0356 (II) RADEON(0): displayWidth=3520 virtualY=1600 pixel_bytes=4 FbMapSize=67108864 maxy=4766 (EE) RADEON(0): Static buffer allocation failed. Disabling DRI. (EE) RADEON(0): At least 66000 kB of video memory needed at this resolution and depth. The patch shows that the required video memory is being calculated from a screen resolution of 3520 x 1600. This happens to be the maximum supported dimensions as reported from the output of xrandr: [a...@srv64 ~]$ xrandr Screen 0: minimum 320 x 200, current 1440 x 1080, maximum 3520 x 1600 VGA-0 connected 1440x1080+0+0 (normal left inverted right x axis y axis) 306mm x 230mm 1440x1080 62.1*+ 1600x1200 60.0 1400x1050 63.3 1280x1024 60.0 1280x960 60.0 1152x864 75.0 1024x768 85.0 75.0 70.1 60.0 43.5 832x62474.6 800x60085.1 85.1 72.2 75.0 60.3 56.2 640x48085.0 75.0 72.8 75.0 66.7 59.9 720x40087.8 85.0 70.1 640x40085.1 640x35085.1 S-video disconnected (normal left inverted right x axis y axis) As you can see, my primary (and only) screen is using a resolution of 1440x1080, the maximum one it supports. But the DRI calculation is being done on 3520 x 1600. Is this the normal behavior of the X server and the radeon driver? I am not really sure, so I am asking here instead of filing a bug. Is there any directive on xorg.conf I can use to reduce the xrandr maximum so that it can fit within the DRI calculation for my system? -- perl -e '$x=2.3;printf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);' ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xvesa black magic
On Thu, Feb 12, 2009 at 6:49 AM, Daniel Stone dan...@fooishbar.org wrote: Is there any particular reason why you can't use the Xorg server with evdev for input (hell, kbd/mouse if you like pain) and the vesa or fbdev driver? I don't know Rene's motivation for wanting Kdrive (I assume that he just wants the smaller memory footprint) but I'm ultimately trying to build against uClibc. Xorg really won't do that. -- William Tracy afishion...@gmail.com -- wtr...@calpoly.edu Vice President, Cal Poly Linux Users' Group http://www.cplug.org I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall, frequently mis-attributed to Voltaire ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-x11-drv-ati for Fedora 10 fails to setup DRI for 3520x1600x32 screen, is this normal?
On Thu, Feb 12, 2009 at 11:59 AM, Alex Villacís Lasso a_villa...@palosanto.com wrote: As you can see, my primary (and only) screen is using a resolution of 1440x1080, the maximum one it supports. But the DRI calculation is being done on 3520 x 1600. Is this the normal behavior of the X server and the radeon driver? I am not really sure, so I am asking here instead of filing a bug. Is there any directive on xorg.conf I can use to reduce the xrandr maximum so that it can fit within the DRI calculation for my system? This is normal. We can't dynamically resize the desktop yet, so we use the virtual parameter to pre-allocate a large enough buffer for for the maximum desktop size requested. Use a smaller virtual line in your xorg.conf. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XKB - xkbcomp can't find keycode includes (Bug?)
Peter Hutterer pisze:
On Wed, Feb 11, 2009 at 10:52:21AM +0100, Jacek Luczak wrote:
Hi All,
xkbcomp fail with message:
The XKEYBOARD keymap compiler (xkbcomp) reports:
Error:Can't find file xfree86 for keycodes include
Exiting
Abandoning keycodes file default
Errors from xkbcomp are not fatal to the X server
(EE) Error compiling keymap (server-0)
(EE) XKB: Couldn't compile keymap
The question is, does it look for those includes in directory specified with
--with-xkb-path?
check include/xkb-config.h. does it say the right path there?
does config.log show your settings?
Hmm.. It's all OK:
/* Path to XKB definitions. */
#define XKB_BASE_DIRECTORY /etc/X11/xkb
/* Path to xkbcomp. */
#define XKB_BIN_DIRECTORY /usr/bin
/* XKB output dir for compiled keymaps. */
#define XKM_OUTPUT_DIR /var/lib/xkb/
I've got xkeyboard-config (ver. 1.5) build with --with-xkb-base set to
/etc/X11/xkb and --with-xkb-path (Xorg-server 1.5.99.902) also set to same
directory. I was trying to use setxkbmap (build with
--with-xkb-config-root=/etc/X11/xkb) but this didn't work. Finally I've
managed
to fix (or workaround) that issue by creating symlink /usr/share/X11/xkb -
/etc/X11/xkb - {datadir}/X11/xkb is mentioned as default for --with-xkb-patch
xorg-server configure option. So does this option work? Maybe it's
responsible
for sth different or this is a bug.
--with-xkb-patch or with-xkb-path (just making sure there's no typo)
No typo here [1].
I can easily reproduce it by removing given link:
$ readlink xkb
/etc/X11/xkb
$ rm xkb
$ setxkbmap -rules xorg -model pc105 -layout pl -v 10
Setting verbose level to 10
locale is C
Warning! Multiple definitions of rules file
Using command line, ignoring X server
Warning! Multiple definitions of keyboard model
Using command line, ignoring X server
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
Applied rules from xorg:
model: pc105
layout: pl
Trying to build keymap using the following components:
keycodes: xfree86+aliases(qwerty)
types: complete
compat: complete
symbols:pc+pl
geometry: pc(pc105)
Error loading new keyboard description
$ ln -sf /etc/X11/xkb xkb
$ setxkbmap -rules xorg -model pc105 -layout pl -v 10
Setting verbose level to 10
locale is C
Warning! Multiple definitions of rules file
Using command line, ignoring X server
Warning! Multiple definitions of keyboard model
Using command line, ignoring X server
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
Applied rules from xorg:
model: pc105
layout: pl
Trying to build keymap using the following components:
keycodes: xfree86+aliases(qwerty)
types: complete
compat: complete
symbols:pc+pl
geometry: pc(pc105)
$ echo $?
0
Any idea how to track down that issue?
-Jacek
--
[1] Xorg-server configure:
configure --prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--infodir=/usr/info \
--mandir=/usr/man \
--disable-ipv6 \
--enable-dri \
--disable-dmx \
--enable-composite \
--enable-xcsecurity \
--enable-xorg \
--enable-xtrap \
--enable-glx-tls \
--enable-xorgcfg \
--enable-install-setuid \
--enable-config-hal \
--enable-config-dbus \
--enable-dri2 \
--disable-xsdl \
--disable-kdrive-vesa \
--disable-xprint \
--disable-static \
--disable-xvfb \
--disable-xnest \
--disable-xquartz \
--with-pic \
--with-int10=x86emu \
--with-default-font-path=/usr/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/75dpi/:unscaled
\
--with-module-dir=/usr/lib/xorg/modules \
--with-dri-driver-path=/usr/lib/xorg/modules/dri \
--with-os-name=Slackware 12.1 \
--with-os-vendor=Beton Project for Slackware Linux Project \
--with-xkb-path=/etc/X11/xkb \
--with-xkb-output=/var/lib/xkb \
--disable-builtin-fonts \
--build=$TARGET
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-x11-drv-ati for Fedora 10 fails to setup DRI for 3520x1600x32 screen, is this normal?
Alex Deucher escribió: On Thu, Feb 12, 2009 at 11:59 AM, Alex Villacís Lasso a_villa...@palosanto.com wrote: As you can see, my primary (and only) screen is using a resolution of 1440x1080, the maximum one it supports. But the DRI calculation is being done on 3520 x 1600. Is this the normal behavior of the X server and the radeon driver? I am not really sure, so I am asking here instead of filing a bug. Is there any directive on xorg.conf I can use to reduce the xrandr maximum so that it can fit within the DRI calculation for my system? This is normal. We can't dynamically resize the desktop yet, so we use the virtual parameter to pre-allocate a large enough buffer for for the maximum desktop size requested. Use a smaller virtual line in your xorg.conf. Alex I have used the Virtual setting and it works (DRI is now enabled). However, I had no Virtual setting before, and the 1440x1080 mode was the biggest one configured in my xorg.conf : Section Screen Identifier Screen0 Device Videocard0 MonitorMonitor0 # DefaultDepth 24 SubSection Display Virtual1440 1080 Viewport 0 0 Depth 24 Modes 1440x1080 1400x1050 1440x1024 1440x900 1280x1024 1280x960 1280x800 1152x864 1152x768 1024x768 800x600 640x480 EndSubSection EndSection The xorg.conf manpage states that the default for Virtual is supposed to accomodate all the screen modes defined. For my case, it should be set to 1440x1080, but chose those bogus values instead. Where did the xserver get those values from? -- perl -e '$x=2.3;printf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);' ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XKB - xkbcomp can't find keycode includes (Bug?)
2009/2/12 mailingli...@openelec.tv can you try build xkeyboard-config with --with-xkb-rules-symlink=xorg i had the same problem and this works now. This is more or less required but didn't helped in my case. I've got --with-xkb-rules-symlink=xorg,xfree86 and only creating symlink in /usr/share/X11 helps. So Zitat try to create such link pointing to same dirctory specified in --with-xkb-base. -Jacek ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-x11-drv-ati for Fedora 10 fails to setup DRI for 3520x1600x32 screen, is this normal?
On Thu, Feb 12, 2009 at 12:25 PM, Alex Villacís Lasso a_villa...@palosanto.com wrote: Alex Deucher escribió: On Thu, Feb 12, 2009 at 11:59 AM, Alex Villacís Lasso a_villa...@palosanto.com wrote: As you can see, my primary (and only) screen is using a resolution of 1440x1080, the maximum one it supports. But the DRI calculation is being done on 3520 x 1600. Is this the normal behavior of the X server and the radeon driver? I am not really sure, so I am asking here instead of filing a bug. Is there any directive on xorg.conf I can use to reduce the xrandr maximum so that it can fit within the DRI calculation for my system? This is normal. We can't dynamically resize the desktop yet, so we use the virtual parameter to pre-allocate a large enough buffer for for the maximum desktop size requested. Use a smaller virtual line in your xorg.conf. Alex I have used the Virtual setting and it works (DRI is now enabled). However, I had no Virtual setting before, and the 1440x1080 mode was the biggest one configured in my xorg.conf : Section Screen Identifier Screen0 Device Videocard0 MonitorMonitor0 # DefaultDepth 24 SubSection Display Virtual1440 1080 Viewport 0 0 Depth 24 Modes 1440x1080 1400x1050 1440x1024 1440x900 1280x1024 1280x960 1280x800 1152x864 1152x768 1024x768 800x600 640x480 EndSubSection EndSection The xorg.conf manpage states that the default for Virtual is supposed to accomodate all the screen modes defined. For my case, it should be set to 1440x1080, but chose those bogus values instead. Where did the xserver get those values from? The driver tries to set sane default sizes, which don't always work out. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xmodmap: different keys have different keycode semantics?
Marius Gedminas mar...@gedmin.as writes:
On Wed, Feb 11, 2009 at 04:19:57PM -0500, Nikolaus Rath wrote:
I noticed a very strange thing about xmodmap. Apparently, the
semantics of the
keycode nr = keysyms
command depend on the keycode.
Yes.
You may find reading about XKB enlightening: http://pascal.tsu.ru/en/xkb/
or http://www.charvolant.org/~doug/xkb/
Specifically, the type assigned to a keycode determines how the various
shift keys select a level.
Thanks a lot. It seems that the use of xmodmap is actually deprecated,
is it?
After reading the website, I was able to translate most of my xmodmap
rules into a new xkb symbol file. However, I am facing problems in
setting up the modifiers.
I am setting them up as follows:
,
| partial
| default
| alphanumeric_keys
| xkb_symbols niko {
|
| // Meta
| key RALT {
| type[Group1]=ONE_LEVEL,
| symbols[Group1] = [ Meta_R ]
| };
| key LALT {
| type[Group1]=ONE_LEVEL,
| symbols[Group1] = [ Alt_L ]
| };
| modifier_map Mod1 { LALT };
| modifier_map Mod3 { RALT };
|
| // Clean up
| modifier_map Lock { Caps_Lock };
| };
`
(note that CAPS is actually bound to Control_L). Unfortunately, the
result looks like this:
,
| nokile:~$ xmodmap
| xmodmap: up to 3 keys per modifier, (keycodes in parentheses):
|
| shift Shift_L (0x32), Shift_R (0x3e)
| lockControl_L (0x42)
| control Control_L (0x25), Control_L (0x42)
| mod1Alt_L (0x40), Meta_R (0x71), Meta_L (0x9c)
| mod2Num_Lock (0x4d)
| mod3Alt_L (0x40)
| mod4Super_L (0x7f), Hyper_L (0x80)
| mod5Mode_switch (0x5d), ISO_Level3_Shift (0x6d), ISO_Level3_Shift
(0x7c)
`
(and obviously this causes a lot of problems). What
what I would like to have is *no* key bound to the lock modifier ,
*only* the Alt_L key bound to mod1 and only the Meta_R key bound to
mod3.
How can I accomplish that? Is there some way to clean up the modifier
table (like with xmodmap)? And why isn't the above file working as I
expect? (The file is actually read in, because with xev I can see that the
keysym of RALT changes to Meta_R as desired).
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
XRandr rotation and hardware acceleration
Hi, I was reading about the XRandR extension here http://keithp.com/~keithp/talks/randr/randr/ and it under the Rotation using Xrandr it mentions this *This implementation causes a slight loss of performance as no rendering is accelerated and also uses additional main memory for a copy of the frame bufffer .* Is this this true for the current implemenation of XRandR - that we could miss out on hardware accleration if we rotate the screen? OR have I misunderstood Keith's statement. -Bipin ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xmodmap: different keys have different keycode semantics?
On Thu, Feb 12, 2009 at 01:51:46PM -0500, Nikolaus Rath wrote: Thanks a lot. It seems that the use of xmodmap is actually deprecated, is it? Looking back at the previous mailing discussion, deprecated is probably the wrong spelling to apply to this issue. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpdUog7UOiTG.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XRandr rotation and hardware acceleration
On Thu, Feb 12, 2009 at 2:36 PM, Bipin George Mathew bipi...@gmail.com wrote: Hi, I was reading about the XRandR extension here http://keithp.com/~keithp/talks/randr/randr/ and it under the Rotation using Xrandr it mentions this This implementation causes a slight loss of performance as no rendering is accelerated and also uses additional main memory for a copy of the frame bufffer . Is this this true for the current implemenation of XRandR - that we could miss out on hardware accleration if we rotate the screen? OR have I misunderstood Keith's statement. Rotation will be accelerated if the driver accelerates composite. In most drivers this means using EXA acceleration. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radeon R6xx/R7xx 3D Register Reference Guide
On Thu, Feb 12, 2009 at 4:22 PM, Richard Wilbur richard.wil...@gmail.com wrote: On Mon, 2009-01-26 at 19:41 -0500, Alex Deucher wrote: AMD is pleased to announce the release of a 3D register reference guide for Radeon 6xx/7xx chips. The guide will be available in the usual places: http://www.x.org/docs/AMD/R6xx_3D_Registers.pdf and http://ati.amd.com/developer/open_gpu_documentation.html If you have any development related questions please ask at gpudriverdevsupp...@amd.com. Alex Deucher AMD GPG alexander.deuc...@amd.com ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati Dear Alex, et al, Where can I find documentation for my ATI Mobility Radeon 9550 (M12 ASIC)? http://www.x.org/docs/AMD/ 3D engine: http://www.x.org/docs/AMD/R3xx_3D_Registers.pdf http://www.x.org/docs/AMD/R5xx_Acceleration_v1.3.pdf the 2D and display information haven't been been formally released, but the radeon driver is a good reference. http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/ Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xmodmap: different keys have different keycode semantics?
On Thu, Feb 12, 2009 at 02:58:52PM -0500, Thomas Dickey wrote: On Thu, Feb 12, 2009 at 01:51:46PM -0500, Nikolaus Rath wrote: Thanks a lot. It seems that the use of xmodmap is actually deprecated, is it? Looking back at the previous mailing discussion, deprecated is probably the wrong spelling to apply to this issue. [citation needed] signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xmodmap: different keys have different keycode semantics?
On Thu, Feb 12, 2009 at 08:01:43PM -0500, Thomas Dickey wrote: On Fri, 13 Feb 2009, Daniel Stone wrote: On Thu, Feb 12, 2009 at 02:58:52PM -0500, Thomas Dickey wrote: On Thu, Feb 12, 2009 at 01:51:46PM -0500, Nikolaus Rath wrote: Thanks a lot. It seems that the use of xmodmap is actually deprecated, is it? Looking back at the previous mailing discussion, deprecated is probably the wrong spelling to apply to this issue. [citation needed] It's too obvious - get one of your cronies to explain it to you. Oooh, I've always wanted some of those. Cool! I'm off to play with them now, bbl. signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xf86-video-intel low glxgears, non-existent OpenGL performance, and general WTF
SETUP [I] x11-base/xorg-server (1.5.3...@11/02/09): X.Org X servers [I] x11-base/xorg-x11 (7...@11/02/09): An X11 implementation maintained by the X.Org Foundation (meta package) [I] x11-drivers/xf86-video-intel (2@11/02/09): X.Org driver for Intel cards [I] media-libs/mesa (7...@11/02/09): OpenGL-like graphic library for Linux [I] x11-apps/mesa-progs (7...@11/02/09): Mesa's OpenGL utility and demo [I] x11-libs/libdrm (2@11/02/09): X.Org libdrm library [I] sys-kernel/gentoo-sources (2.6.28-r1(2.6.28-r1)@12/02/09): Full sources including the Gentoo patchset for the 2.6 kernel tree Section Device Identifier intel Driver intel VendorName Intel Corporation BoardNameIntel Corporation Mobile 945GM/GMS/GME Express Integrated Graphics Controller VideoRAM 16384 # # Acceleration options Option FramebufferCompression true Option Tilingtrue Option DRI true Option XVideotrue Option Legacy3D false Option TripleBuffer false Option AccelMethod UXA # XAA, EXA, UXA Option XvMC false # Other options OptionBackingStore true OptionPageFlip true EndSection Questions: So glxgears runs at 62fps, and I think I saw something about it's now locked to vsync. So that's fine I guess. But that doesn't explain why WoW runs like crap. OpenGL is non existent, either X doesn't update the screen or it's renders tons of crap (this is with WoW). I have tried every version of wine/WoW that I could confirm working (on ATI/Nvidia) so I'm pretty sure that leaves the intel driver or X. Other then that compositing and junk works fine, some stuttering but nothing really annoying. Mind you mplayer hates it when I have compositing on, but xv is the only video output driver that works well with 720p and up. But I guess they don't need the horse power that games do. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xmodmap: different keys have different keycode semantics?
On Thu, Feb 12, 2009 at 01:51:46PM -0500, Nikolaus Rath wrote:
Marius Gedminas mar...@gedmin.as writes:
On Wed, Feb 11, 2009 at 04:19:57PM -0500, Nikolaus Rath wrote:
I noticed a very strange thing about xmodmap. Apparently, the
semantics of the
keycode nr = keysyms
command depend on the keycode.
Yes.
You may find reading about XKB enlightening: http://pascal.tsu.ru/en/xkb/
or http://www.charvolant.org/~doug/xkb/
Specifically, the type assigned to a keycode determines how the various
shift keys select a level.
Thanks a lot. It seems that the use of xmodmap is actually deprecated,
is it?
After reading the website, I was able to translate most of my xmodmap
rules into a new xkb symbol file. However, I am facing problems in
setting up the modifiers.
I am setting them up as follows:
,
| partial
| default
| alphanumeric_keys
| xkb_symbols niko {
|
| // Meta
| key RALT {
| type[Group1]=ONE_LEVEL,
| symbols[Group1] = [ Meta_R ]
| };
| key LALT {
| type[Group1]=ONE_LEVEL,
| symbols[Group1] = [ Alt_L ]
| };
| modifier_map Mod1 { LALT };
| modifier_map Mod3 { RALT };
|
| // Clean up
| modifier_map Lock { Caps_Lock };
| };
`
(note that CAPS is actually bound to Control_L). Unfortunately, the
result looks like this:
,
| nokile:~$ xmodmap
| xmodmap: up to 3 keys per modifier, (keycodes in parentheses):
|
| shift Shift_L (0x32), Shift_R (0x3e)
| lockControl_L (0x42)
| control Control_L (0x25), Control_L (0x42)
| mod1Alt_L (0x40), Meta_R (0x71), Meta_L (0x9c)
| mod2Num_Lock (0x4d)
| mod3Alt_L (0x40)
| mod4Super_L (0x7f), Hyper_L (0x80)
| mod5Mode_switch (0x5d), ISO_Level3_Shift (0x6d), ISO_Level3_Shift
(0x7c)
`
(and obviously this causes a lot of problems). What
what I would like to have is *no* key bound to the lock modifier ,
*only* the Alt_L key bound to mod1 and only the Meta_R key bound to
mod3.
How can I accomplish that? Is there some way to clean up the modifier
table (like with xmodmap)? And why isn't the above file working as I
expect? (The file is actually read in, because with xev I can see that the
keysym of RALT changes to Meta_R as desired).
the rules have funny ways of combining themselves, so your best guess is to
look at the output of xkbcomp -xkb :0 - and compare what it says.
For example, an explicit NoSymbol is overwritten by a symbol pulled in from a
different data set. I don't think there's a way of avoiding that.
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel low glxgears, non-existent OpenGL performance, and general WTF
On Friday 13 February 2009 05:55:22 Weedy wrote: SETUP [I] x11-base/xorg-server (1.5.3...@11/02/09): X.Org X servers [I] x11-base/xorg-x11 (7...@11/02/09): An X11 implementation maintained by the X.Org Foundation (meta package) [I] x11-drivers/xf86-video-intel (2@11/02/09): X.Org driver for Intel cards [I] media-libs/mesa (7...@11/02/09): OpenGL-like graphic library for Linux [I] x11-apps/mesa-progs (7...@11/02/09): Mesa's OpenGL utility and demo [I] x11-libs/libdrm (2@11/02/09): X.Org libdrm library [I] sys-kernel/gentoo-sources (2.6.28-r1(2.6.28-r1)@12/02/09): Full sources including the Gentoo patchset for the 2.6 kernel tree Section Device Identifier intel Driver intel VendorName Intel Corporation BoardNameIntel Corporation Mobile 945GM/GMS/GME Express Integrated Graphics Controller VideoRAM 16384 # # Acceleration options Option FramebufferCompression true Option Tilingtrue Option DRI true Option XVideotrue Option Legacy3D false Option TripleBuffer false Option AccelMethod UXA # XAA, EXA, UXA Option XvMC false # Other options OptionBackingStore true OptionPageFlip true EndSection Questions: So glxgears runs at 62fps, and I think I saw something about it's now locked to vsync. So that's fine I guess. But that doesn't explain why WoW runs like crap. OpenGL is non existent, either X doesn't update the screen or it's renders tons of crap (this is with WoW). I have tried every version of wine/WoW that I could confirm working (on ATI/Nvidia) so I'm pretty sure that leaves the intel driver or X. Other then that compositing and junk works fine, some stuttering but nothing really annoying. Mind you mplayer hates it when I have compositing on, but xv is the only video output driver that works well with 720p and up. But I guess they don't need the horse power that games do. With gentoo-sources-2.6.27-r8 and AccelMethod EXA you'll get your 3D I have same issues, and I've filed bugs on freedesktop bugzilla, here they're: http://bugs.freedesktop.org/show_bug.cgi?id=19873 http://bugs.freedesktop.org/show_bug.cgi?id=19738 So, I think we just have to wait till intel developers fix these issues :) Regards Vasily signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
