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: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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: input.joystick joystick 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: [Xlib] Saving state before an unmap
On Wednesday 11 of February 2009, Andrew Troschinetz wrote: > Hi all, > > Basically I want to unmap a window, fiddle with it a bit (like > removing the border, removing the maximize button, etc...) and then > remap it. The problem I'm running into is that unmapping the window > results in unintended side-effects. Take the _NET_WM_STATE property > for example, it gets blown away if you unmap the window. This results > in things like a window being kept-below before I fiddle with it, but > then after I remap it, the window will no longer be kept-below anymore. ... > There has to be a better way, right? Yes, there is: Don't fiddle with it. There are requests for asking to change some properties while a window is mapped. From the window manager's point of view, unmapping a window and destroying a window is about the same. > Alternatively, if there is a way to remove the close/minimize/maximize > buttons or window-decorations from a window w/o unmapping it (or w/o > losing the window's current _NET_WM_STATE property) that'd be awesome. No, there is not. Altering the window decorations/buttons is something under the control of a window manager and many of them do that based on what makes sense and not on what some application thinks would look cool. > Essentially, I'm writing a "window-manager-lite on top of a real > window manager" so that I can manipulate all the windows of all the > disparate applications of the software suite I'm developing in various > ways. It's a little complicated, but probably not as complicated as > I'm making it sound. Essentially the use case is that the user may at > any point command the window of another application to remove (or un- > remove) its border/close-button/etc, and I need to respect as much of > the current window state of the target window as possible (ie: > _NET_WM_STATE and possibly other Extended Window Manager Hints > properties that I haven't even thought of yet.) > > Any ideas? I think you should try to find somewhere a good description of what a window manager is, and specifically why it has 'manager' in its name - it is the window manager that is eventually in control of the windows and not the other way around. The more complicated things you try the more likely is that the window manager will have a different idea about it, so I suggest you instead consider to try to add your wanted features to your favorite window manager. -- Lubos Lunak KDE developer -- SUSE LINUX, s.r.o. e-mail: l.lu...@suse.cz , l.lu...@kde.org Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz ___ 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 - ( 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 - ( PID: ? ):
pixmap bytes : 207920
other bytes : ~6520
total bytes : ~214440
5 - ( 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 : 3038
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 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 : > 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: [PATCH 07/13] Cygwin/X: Correctly allow for the native window frame width in ValidateSizing()
Colin Harrison wrote:
> Hi,
>
> Jon wrote
>> XXX: Needs to allow for different border thickness when window is
> uncaptioned?
>
> I found this works for me...
> --- ./save_winmultiwindowwndproc.c2009-01-19 18:42:49.0 +
> +++ ./winmultiwindowwndproc.c 2009-01-19 18:43:30.0 +
> @@ -207,6 +209,7 @@
> - /* Now remove size of any borders */
> - iWidth -= 2 * GetSystemMetrics(SM_CXSIZEFRAME);
> - iHeight -= (GetSystemMetrics(SM_CYCAPTION)
> - + 2 * GetSystemMetrics(SM_CYSIZEFRAME));
> -
> + /* Now remove size of any borders and title bar */
> + gwlStyle = GetWindowLongPtr(hwnd, GWL_STYLE);
> + if (gwlStyle & WS_CAPTION)
> + iHeight -= GetSystemMetrics(SM_CYCAPTION);
> + else
> +{
> + iWidth += 2; /* Small fiddle factors as sizebox appears to be */
> + iHeight += 2; /* not the same thickness with and without a caption */
> +}
> + if (gwlStyle & WS_SIZEBOX)
> +{
> + iWidth -= 2 * GetSystemMetrics(SM_CXSIZEFRAME);
> + iHeight -= 2 * GetSystemMetrics(SM_CYSIZEFRAME);
> +}
Hmm... perhaps it would be better (less brittle) if it used the difference
between GetClientRect() and GetWindowRect() to find the size of the native
window frame and decorations, rather than trying to understand all the WS_
style bits? So something like the following? (This appears to disagree with
the initial window sizing, though...)
diff --git a/hw/xwin/winmultiwindowwndproc.c b/hw/xwin/winmultiwindowwndproc.c
index b5e789c..0dd8885 100644
--- a/hw/xwin/winmultiwindowwndproc.c
+++ b/hw/xwin/winmultiwindowwndproc.c
@@ -207,6 +207,8 @@ ValidateSizing (HWND hwnd, WindowPtr pWin,
WinXSizeHints sizeHints;
RECT *rect;
int iWidth, iHeight;
+ RECT rcClient, rcWindow;
+ int iBorderWidthX, iBorderWidthY;
/* Invalid input checking */
if (pWin==NULL || lParam==0)
@@ -228,19 +230,20 @@ ValidateSizing (HWND hwnd, WindowPtr pWin,
iWidth = rect->right - rect->left;
iHeight = rect->bottom - rect->top;
- /* Now remove size of any borders */
- iWidth -= 2 * GetSystemMetrics(SM_CXSIZEFRAME);
- iHeight -= (GetSystemMetrics(SM_CYCAPTION)
- + 2 * GetSystemMetrics(SM_CYSIZEFRAME));
-
+ /* Now remove size of any borders and title bar */
+ GetClientRect(hwnd, &rcClient);
+ GetWindowRect(hwnd, &rcWindow);
+ iBorderWidthX = (rcWindow.right - rcWindow.left) - (rcClient.right -
rcClient.left);
+ iBorderWidthY = (rcWindow.bottom - rcWindow.top) - (rcClient.bottom -
rcClient.top);
+ iWidth -= iBorderWidthX;
+ iHeight -= iBorderWidthY;
/* Constrain the size to legal values */
ConstrainSize (sizeHints, &iWidth, &iHeight);
- /* Add back the borders */
- iWidth += 2 * GetSystemMetrics(SM_CXSIZEFRAME);
- iHeight += (GetSystemMetrics(SM_CYCAPTION)
- + 2 * GetSystemMetrics(SM_CYSIZEFRAME));
+ /* Add back the size of borders and title bar */
+ iWidth += iBorderWidthX;
+ iHeight += iBorderWidthY;
/* Adjust size according to where we're dragging from */
switch(wParam) {
___
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 > 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 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 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
> 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"
Monitor"Monitor0"
# 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 > > 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 wrote: > Alex Deucher escribió: >> On Thu, Feb 12, 2009 at 11:59 AM, Alex Villacís Lasso >> 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" >Monitor"Monitor0" > # 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 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 =
>>
>> 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 {
| type[Group1]="ONE_LEVEL",
| symbols[Group1] = [ Meta_R ]
| };
| key {
| type[Group1]="ONE_LEVEL",
| symbols[Group1] = [ Alt_L ]
| };
| modifier_map Mod1 { };
| modifier_map Mod3 { };
|
| // Clean up
| modifier_map Lock { Caps_Lock };
| };
`
(note that 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 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 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 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 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. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ 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" BoardName"Intel Corporation Mobile 945GM/GMS/GME Express Integrated Graphics Controller" VideoRAM 16384 # # Acceleration options Option "FramebufferCompression" "true" Option "Tiling""true" Option "DRI" "true" Option "XVideo""true" Option "Legacy3D" "false" Option "TripleBuffer" "false" Option "AccelMethod" "UXA" # XAA, EXA, UXA Option "XvMC" "false" # Other options Option"BackingStore" "true" Option"PageFlip" "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 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 =
> >>
> >> 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 {
> | type[Group1]="ONE_LEVEL",
> | symbols[Group1] = [ Meta_R ]
> | };
> | key {
> | type[Group1]="ONE_LEVEL",
> | symbols[Group1] = [ Alt_L ]
> | };
> | modifier_map Mod1 { };
> | modifier_map Mod3 { };
> |
> | // Clean up
> | modifier_map Lock { Caps_Lock };
> | };
> `
>
> (note that 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 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" > BoardName"Intel Corporation Mobile 945GM/GMS/GME Express > Integrated Graphics Controller" > VideoRAM 16384 > > # # Acceleration options > Option "FramebufferCompression" "true" > Option "Tiling""true" > Option "DRI" "true" > Option "XVideo""true" > Option "Legacy3D" "false" > Option "TripleBuffer" "false" > Option "AccelMethod" "UXA" # XAA, EXA, UXA > Option "XvMC" "false" > > # Other options > Option"BackingStore" "true" > Option"PageFlip" "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
