Large scale X
Hi, If i have 1000 user accounts on one accounts server and dozens of X apps on another apps server, how can a user start an X app when they don't have an account on the apps server? (no user accounts at all on apps server) I'm thinking of traditional X where the users use dumb X terminals, and xdm gives the log-in screen. Do i need to use nfs, or is there some better way? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RandR support for Xvfb
On Tue, May 26, 2009 at 2:42 PM, Alan Coopersmith alan.coopersm...@sun.com wrote: Peter Åstrand wrote: RandR support has been added to the Xvnc implementation in the TigerVNC project (also included in Fedora 11). Since Xvfb has so many bugs, I believe Xvnc is a better choice in most cases. The Xorg server with the xf86-video-dummy and xf86-input-void drivers also approximates Xvfb, though without the ability to connect and see the output as needed that Xvnc will provide (unless you also install the vnc.so Xorg module). I believe Antoine was asking with an eye towards use with 'xpra', which is a sort of rootless VNC equivalent that plays some tricks with compositing on a headless server (http://partiwm.org/wiki/xpra). So using Xvnc would be somewhat silly, but then, there are worse things than silliness. I haven't run into any particular bugs in Xvfb (well, except for not supporting RandR), so I didn't realize Xvnc was better maintained, but if so... Alan: Is there any way for a regular user to spawn a headless Xorg process using those modules? Reading the man page did not give me much hope, but I'm not sure if I'm missing something (e.g., Xorg -showopts just segfaults on my machine). Thanks for the help, -- Nathaniel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Tue, 2009-05-26 at 11:50 +1000, Peter Hutterer wrote: The main benefit of a grab in the use of menus is that you will get the next event regardless of where it occurs. This is what makes the menu disappear when you click elsewhere. If the application didn't grab, the menu could only disappear by activating a menu item, or - assuming the application supports this - by clicking elsewhere in one of the application's windows. Just as a datapoint, AFAIK that's how Windows GUI toolkits work. They don't grab the whole display, thay just wait for events in their window. Any suggestions on solving this feature through other means is appreciated (note that registering for events on every visible window doesn't count). Limiting events to the application windows doesn't seem that bad. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RandR support for Xvfb
Nathaniel Smith wrote: I believe Antoine was asking with an eye towards use with 'xpra', which is a sort of rootless VNC equivalent that plays some tricks with compositing on a headless server (http://partiwm.org/wiki/xpra). So using Xvnc would be somewhat silly, but then, there are worse things than silliness. I haven't run into any particular bugs in Xvfb (well, except for not supporting RandR), so I didn't realize Xvnc was better maintained, but if so... The 90% of Xvfb code that's shared with Xorg is well maintained, the Xvfb ddx layer itself doesn't get that much attention. As for Xvnc, it depends on which Xvnc you use - RealVNC's is basically unmaintained now, but TigerVNC seems to be doing well for a new project, and TightVNC TurboVNC are still alive as well. Alan: Is there any way for a regular user to spawn a headless Xorg process using those modules? Reading the man page did not give me much hope, but I'm not sure if I'm missing something (e.g., Xorg -showopts just segfaults on my machine). Unfortunately, choosing which modules to load is restricted to root, since Xorg is setuid root, so a admin would have to set it up for them. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: up-arrow key not working again.
Robin Cook wrote: I upgraded xorg-server to 1.6.1 and now the up-arrow key is not working the way it is supposed to. When I hit it in gnome it causes the screenshot applet to pop up. I have this same problem, but *only* when running inside an Xnest. I'm running xorg-server 1.6.1.901. I have no xorg.conf. I have xf86-input-evdev installed, and no x-i-mouse or x-i-keyboard. The only strange thing I'm doing is using the colemak keyboard layout in my main server, but not in the nested server. I haven't tried qwerty to see if it changes anything. -- dolphinling http://dolphinling.net/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Xorg resolution with VGA Switch
Hi, I bought a VGA switch to switch some devices on one monitor. But resolution of my X session is limited to 1024x768 instead of 1920x1200. If I hotplug the switch when the X session is started in 1920x1200, it works. Could you help me ? Regards, Aurelien the vga switch: http://aprovin.linux62.org/others/forums/vga_switch_back.jpg http://aprovin.linux62.org/others/forums/vga_switch_front.jpg xrandr --query (no vga switch) : Screen 0: minimum 320 x 240, current 1920 x 1200, maximum 1920 x 1200 default connected 1920x1200+0+0 0mm x 0mm 1920x1200 50.0* 1920x1080 51.0 1680x1050 52.0 53.0 1600x1200 54.0 1440x900 55.0 56.0 1400x1050 57.0 58.0 59.0 1360x768 60.0 61.0 1280x1024 62.0 63.0 64.0 65.0 1280x960 66.0 1152x864 67.0 68.0 69.0 70.0 1024x768 71.0 72.0 73.0 960x60074.0 960x54075.0 840x52576.0 77.0 78.0 79.0 832x62480.0 800x60081.0 82.0 83.0 84.0 720x45085.0 700x52586.0 87.0 680x38488.0 89.0 640x48090.0 91.0 92.0 512x38493.0 94.0 400x30095.0 320x24096.0 97.0 xrandr --query (with vga switch) : Screen 0: minimum 320 x 240, current 1024 x 768, maximum 1024 x 768 default connected 1024x768+0+0 0mm x 0mm 1024x768 50.0* 800x60051.0 52.0 53.0 680x38454.0 55.0 640x48056.0 512x38457.0 400x30058.0 320x24059.0 Xorg.conf : Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbRules xorg Option XkbModel pc105 Option XkbLayout fr Option XkbVariantlatin9 EndSection Section InputDevice Identifier Configured Mouse Driver mouse EndSection Section Device Identifier Configured Video Device Driver nvidia Option RenderAccel true EndSection Section Monitor Identifier Configured Monitor EndSection Section Screen Identifier Default Screen Monitor Configured Monitor Option backingstore true EndSection Section Extensions Option Composite Enable EndSection ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg resolution with VGA Switch
On Wed, May 27, 2009 at 07:49:18AM -0700, Aurélien PROVIN wrote: Hi, I bought a VGA switch to switch some devices on one monitor. But resolution of my X session is limited to 1024x768 instead of 1920x1200. If I hotplug the switch when the X session is started in 1920x1200, it works. It sounds like the switch is preventing the hardware from reading the EDID from the monitor. Check /var/log/Xorg.0.log for warnings to that effect. If that is the case, then your best bet might be to save the EDID to a file by clicking the Acquire EDID button in nvidia-settings when the monitor is connected directly, then feed it back to the driver by using the CustomEDID option in /etc/X11/xorg.conf. See the README for more details on how to do that. Please direct further questions to linux-b...@nvidia.com. Hope that helps! -- Aaron ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
us-intl-unicode: XKB us(intl) variant using Unicode combining characters
I just wrote this in half an hour, thought someone might be interested. It’s a keyboard layout similar to us(altgr-intl), but employing Unicode combining characters instead of X compose sequences. http://github.com/leoboiko/us-intl-unicode -- Leonardo Boiko http://namakajiri.net ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 1/2] kdrive: add protocol mouse option
Peter Hutterer peter.hutte...@who-t.net writes:
On Tue, May 26, 2009 at 03:30:08PM +0200, Olivier Blin wrote:
kdrive probes a lot of PS/2 protocols for the mouse device, which
makes the mouse unusable for some seconds after X startup.
This new protocol option allows forcing the mouse protocol.
It can be used this way:
Xfbdev -mouse mouse,,protocol=ps/2 -keybd keyboard
Signed-off-by: Olivier Blin bl...@mandriva.com
---
hw/kdrive/linux/mouse.c |4 +++-
hw/kdrive/src/kdrive.h |1 +
hw/kdrive/src/kinput.c |3 +++
3 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/hw/kdrive/linux/mouse.c b/hw/kdrive/linux/mouse.c
index 02214b3..253da26 100644
--- a/hw/kdrive/linux/mouse.c
+++ b/hw/kdrive/linux/mouse.c
@@ -961,7 +961,9 @@ MouseInit (KdPointerInfo *pi)
km = (Kmouse *) xalloc (sizeof (Kmouse));
if (km) {
km-iob.avail = km-iob.used = 0;
-MouseFirstProtocol(km, exps/2);
+MouseFirstProtocol(km, pi-force_protocol ? pi-force_protocol :
exps/2);
+if (pi-force_protocol)
+km-state = MouseWorking;
km-i_prot = 0;
km-tty = isatty (fd);
km-iob.fd = -1;
diff --git a/hw/kdrive/src/kdrive.h b/hw/kdrive/src/kdrive.h
index c60559a..c025144 100644
--- a/hw/kdrive/src/kdrive.h
+++ b/hw/kdrive/src/kdrive.h
@@ -220,6 +220,7 @@ struct _KdPointerInfo {
DeviceIntPtr dixdev;
char *name;
char *path;
+char *force_protocol;
InputOption *options;
int inputClass;
diff --git a/hw/kdrive/src/kinput.c b/hw/kdrive/src/kinput.c
index 0d216a9..5f82ba4 100644
--- a/hw/kdrive/src/kinput.c
+++ b/hw/kdrive/src/kinput.c
@@ -1166,6 +1166,8 @@ KdParsePointerOptions (KdPointerInfo *pi)
pi-transformCoordinates = FALSE;
else if (!strcasecmp (option-key, device))
pi-path = strdup(option-value);
+else if (!strcasecmp (option-key, protocol))
+pi-force_protocol = strdup(option-value);
else
ErrorF(Pointer option key (%s) of value (%s) not assigned!\n,
option-key, option-value);
@@ -1186,6 +1188,7 @@ KdParsePointer (char *arg)
return NULL;
pi-emulateMiddleButton = kdEmulateMiddleButton;
pi-transformCoordinates = !kdRawPointerCoordinates;
+pi-force_protocol = NULL;
pi-nButtons = 5; /* XXX should not be hardcoded */
pi-inputClass = KD_MOUSE;
--
1.6.2.4
wouldn't it be better to name the option protocol instead of
force_protocol to reflect the cmdline option?
I used the force_ prefix mainly to indicate it is optional, but it's
ok to just name it protocol (note that device option and pi-path have
the same issue, if we want to be picky).
Do you want me to resend the patch using protocol as field name?
Thanks for your input
--
Olivier Blin (blino) - Mandriva
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/2] kdrive: do not undef DEBUG macro in mouse driver
Peter Hutterer peter.hutte...@who-t.net writes: On Tue, May 26, 2009 at 03:30:14PM +0200, Olivier Blin wrote: The mouse driver had some code to unconditionnally disable debug, even if configured with --enable-debug. This adds back the mouse driver debug output when built with debug option. Signed-off-by: Olivier Blin bl...@mandriva.com --- hw/kdrive/linux/mouse.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/hw/kdrive/linux/mouse.c b/hw/kdrive/linux/mouse.c index 253da26..8b638ae 100644 --- a/hw/kdrive/linux/mouse.c +++ b/hw/kdrive/linux/mouse.c @@ -32,7 +32,6 @@ #include scrnintstr.h #include kdrive.h -#undef DEBUG #undef DEBUG_BYTES what about DEBUG_BYTES? Is that of any importance? Why is it undef'd? It looks extremly verbose to enable it, I think it would pollute logs too much to enable it if DEBUG is on. I guess it is undef'd explicitely at the top of the file so that people debugging notice it can be enabled (this code dates from 2001) -- Olivier Blin (blino) - Mandriva ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[xf86-video-ati] crash with latest code from git (possibly radeon-rewrite related)
I've run into an X server crash with the latest radeon driver from git, packaged for Ubuntu Jaunty by Tormod Volden. I'm also using the radeon-rewrite mesa branch, which I have been using for a few weeks now, however this bug seems to be related to my recent upgrade of the xf86-video-ati driver. (I have not attempted to rollback the driver to confirm this.) From the .deb changelog: xserver-xorg-video-ati (1:6.12.99+git20090526.b34df233-0ubuntu0tormod) jaunty; urgency=low * Checkout from git 20090526 (master branch) up to commit b34df233115c0d82d7bcf82e041afbc55981ce82 * Merge with origin/debian-experimental * hook: Log git commit id in RadeonPreInit() Backtrace: 0: /usr/bin/X(xorg_backtrace+0x3b) [0x813518b] 1: /usr/bin/X(xf86SigHandler+0x55) [0x80c7be5] 2: [0xb7f80400] 3: /usr/lib/dri/r300_dri.so(radeonAllocDmaRegion+0xba) [0xb13a2c2a] 4: /usr/lib/dri/r300_dri.so(rcommon_emit_vector+0x12f) [0xb13a2def] 5: /usr/lib/dri/r300_dri.so(r300EmitArrays+0x1de) [0xb13981ee] 6: /usr/lib/dri/r300_dri.so [0xb1386d61] 7: /usr/lib/dri/r300_dri.so [0xb1387510] 8: /usr/lib/dri/r300_dri.so(_tnl_run_pipeline+0x164) [0xb14445e4] 9: /usr/lib/dri/r300_dri.so(_tnl_draw_prims+0x535) [0xb1444bf5] 10: /usr/lib/dri/r300_dri.so(vbo_exec_vtx_flush+0xfc) [0xb143d09c] 11: /usr/lib/dri/r300_dri.so(vbo_exec_FlushVertices_internal+0x40) [0xb1439e40] 12: /usr/lib/dri/r300_dri.so(vbo_exec_FlushVertices+0x50) [0xb1439ef0] 13: /usr/lib/dri/r300_dri.so(_mesa_set_scissor+0xb9) [0xb1405de9] 14: /usr/lib/dri/r300_dri.so(_mesa_Scissor+0x56) [0xb1405e96] 15: /usr/lib/xorg/modules/extensions//libglx.so [0xb78cab8e] 16: /usr/lib/xorg/modules/extensions//libglx.so [0xb78f546f] 17: /usr/lib/xorg/modules/extensions//libglx.so [0xb78f9d6a] 18: /usr/bin/X(Dispatch+0x33f) [0x808d57f] 19: /usr/bin/X(main+0x3bd) [0x80722ed] 20: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7b41775] 21: /usr/bin/X [0x80717a1] Saw signal 11. Server aborting. lspci -vvnn 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] [1002:4e50] Subsystem: IBM Device [1014:0550] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+ DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 66 (2000ns min), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at e000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 3000 [size=256] Region 2: Memory at c010 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at c012 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x1 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel modules: radeonfb I've had this crash happen a few times, and it appears that the backtrace is identical each time. Some relevant package/version info: xserver-xorg-core 2:1.6.0-0ubuntu14 libgl1-mesa-dri 7.6.0~git20090524+radeon-rewrite.7dd184dc-0ubuntu0tormod linux-image-generic 2.6.28.12.16 Steps to reproduce: I've found that I can reproduce the bug with Amarok (v2.0.2 with KDE 4.2.2). In the Collection panel (left side pane), as soon as I click the Advanced button at the X server crashes. (The screen goes blank, and apparently changes size--based on the fact that the mouse cursor shows about 4-8 times larger than normal. Then a new X session starts up again via KDM.) Thanks, - Lowell Alleman ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xf86-video-ati] crash with latest code from git (possibly radeon-rewrite related)
On Wed, May 27, 2009 at 3:50 PM, Lowell Alleman low...@allemansonline.com wrote: I've run into an X server crash with the latest radeon driver from git, packaged for Ubuntu Jaunty by Tormod Volden. I'm also using the radeon-rewrite mesa branch, which I have been using for a few weeks now, however this bug seems to be related to my recent upgrade of the xf86-video-ati driver. (I have not attempted to rollback the driver to confirm this.) From the .deb changelog: xserver-xorg-video-ati (1:6.12.99+git20090526.b34df233-0ubuntu0tormod) jaunty; urgency=low * Checkout from git 20090526 (master branch) up to commit b34df233115c0d82d7bcf82e041afbc55981ce82 * Merge with origin/debian-experimental * hook: Log git commit id in RadeonPreInit() Backtrace: 0: /usr/bin/X(xorg_backtrace+0x3b) [0x813518b] 1: /usr/bin/X(xf86SigHandler+0x55) [0x80c7be5] 2: [0xb7f80400] 3: /usr/lib/dri/r300_dri.so(radeonAllocDmaRegion+0xba) [0xb13a2c2a] 4: /usr/lib/dri/r300_dri.so(rcommon_emit_vector+0x12f) [0xb13a2def] 5: /usr/lib/dri/r300_dri.so(r300EmitArrays+0x1de) [0xb13981ee] 6: /usr/lib/dri/r300_dri.so [0xb1386d61] 7: /usr/lib/dri/r300_dri.so [0xb1387510] 8: /usr/lib/dri/r300_dri.so(_tnl_run_pipeline+0x164) [0xb14445e4] 9: /usr/lib/dri/r300_dri.so(_tnl_draw_prims+0x535) [0xb1444bf5] 10: /usr/lib/dri/r300_dri.so(vbo_exec_vtx_flush+0xfc) [0xb143d09c] 11: /usr/lib/dri/r300_dri.so(vbo_exec_FlushVertices_internal+0x40) [0xb1439e40] 12: /usr/lib/dri/r300_dri.so(vbo_exec_FlushVertices+0x50) [0xb1439ef0] 13: /usr/lib/dri/r300_dri.so(_mesa_set_scissor+0xb9) [0xb1405de9] 14: /usr/lib/dri/r300_dri.so(_mesa_Scissor+0x56) [0xb1405e96] 15: /usr/lib/xorg/modules/extensions//libglx.so [0xb78cab8e] 16: /usr/lib/xorg/modules/extensions//libglx.so [0xb78f546f] 17: /usr/lib/xorg/modules/extensions//libglx.so [0xb78f9d6a] 18: /usr/bin/X(Dispatch+0x33f) [0x808d57f] 19: /usr/bin/X(main+0x3bd) [0x80722ed] 20: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7b41775] 21: /usr/bin/X [0x80717a1] Saw signal 11. Server aborting. The crash above is in the 3D driver, so it's probably mesa related. May be similar to bug 21582: https://bugs.freedesktop.org/show_bug.cgi?id=21582 Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Mod4 ignored?
Seriously, noone? Can't believe this is a difficult problem to solve. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: up-arrow key not working again.
I have the AllowEmptyInput but not the AutoAddDevices.
Section ServerFlags
Option AllowEmptyInput false
EndSection
The two option were what I was told to put in there and it was working
on the previous version with the patch.
Thanks
CuZnDragon
Robin Cook
On Wed, 2009-05-27 at 12:58 +1000, Peter Hutterer wrote:
On Tue, May 26, 2009 at 08:14:44PM -0500, Robin Cook wrote:
Yes I have xkeyboard-config 1.5
Section InputDevice
Identifier Keyboard0
Driver kbd
Option Protocol evdev
Option Dev Phys isa0060/serio0/input0
I don't think the kbd driver supports these two options.
Option XkbRules Xorg
Option XkbModel pc104
Option XkbLayout us
Option XkbVariant dvorak
EndSection
xkb_keymap {
xkb_keycodes { include evdev+aliases(qwerty) };
xkb_types { include complete };
xkb_compat{ include complete };
xkb_symbols { include pc+us(dvorak)+us:2
+inet(evdev)+level3(ralt_switch_for_alts_toggle):1
+level3(ralt_switch_for_alts_toggle):2+group(alts_toggle) };
xkb_geometry { include pc(pc104) };
};
There's some combination of configurations that's screwing up.
this output indicates that you're using the evdev ruleset. Do you have
AutoAddDevices or AllowEmptyInput off? otherwise the kbd section will just
be ignored anyway.
Cheers,
Peter
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 1/2] kdrive: add protocol mouse option
Am Dienstag, den 26.05.2009, 15:30 +0200 schrieb Olivier Blin: kdrive probes a lot of PS/2 protocols for the mouse device, which makes the mouse unusable for some seconds after X startup. This new protocol option allows forcing the mouse protocol. It can be used this way: Xfbdev -mouse mouse,,protocol=ps/2 -keybd keyboard Signed-off-by: Olivier Blin bl...@mandriva.com --- hw/kdrive/linux/mouse.c |4 +++- hw/kdrive/src/kdrive.h |1 + hw/kdrive/src/kinput.c |3 +++ 3 files changed, 7 insertions(+), 1 deletions(-) I have no clue, but should this new option be documented in the help output or manpage? Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Is there the possibility to support EXA for legacy S3 chips?
I have made the first attempt to implement basic `Copy' and `Solid' EXA functions in xf86-video-s3, but soon came to intention that EXA support is not possible. Is there mistake in my thinking below? S3's Graphic Processor (S3 GP) is able to copy areas only in terms of coordinates, i. e. it can copy rectangle from (src-x, src-y) to (dest-x, dest-y) with width w and height h (Fig. 1). This method is used in XAA ScreenToScreenCopy function. But S3 GP hasn't mean to copy offscreen pixmaps in format presented on Fig. 2 to framebuffer, i. e. there is no way to write the pixmap's offset and pitch directly into GP registers to make subsequent copying. I looked up on the code of few other drivers where EXA is implemented (ati, trident, mga) -- all these chips have the possibility to write offset and pitch of pixmap into their GP. Although the method (by means of Pixel Transfer Register) exists to upload pixmap from the system memory to S3's offscreen memory in required format (Fig. 1) (I didn't try it), such offscreen memory organization will not be understandable to the EXA offscreen memory manager. Most probably this will follow to incorrect pixmap migration and overwriting previously uploaded pixmaps. The objection above sounds like the judgement to EXA support in S3 driver. No? --- 800 * 4 Bpp 0 == - . ===11= | . ===22= | . ===33= 600 scanlines (Framebuffer) . ===44= | 599 == | 600 11 - . 22 | . 33 | . 44 55 scanlines (Offscreen) . == | . == | 654 == - Fig. 1. S3 GP fb and offscreen representation, 800x600/32bpp, 2Mb video RAM (655 scanlines). --- 800 * 4 Bpp 0 == - . ===11= | . ===22= | . ===33= 600 scanlines (Framebuffer) . ===44= | 599 == | 600 112233 - . 44 | . == | . == 55 scanlines (Offscreen) . == | . == | 654 == - Fig. 2. EXA Pixmap in offscreen, 800x600/32bpp, 2Mb video RAM (655 scanlines) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On Wed, May 27, 2009 at 5:09 PM, Evgeny M. Zubok evgeny.zu...@tochka.ru wrote: I have made the first attempt to implement basic `Copy' and `Solid' EXA functions in xf86-video-s3, but soon came to intention that EXA support is not possible. Is there mistake in my thinking below? S3's Graphic Processor (S3 GP) is able to copy areas only in terms of coordinates, i. e. it can copy rectangle from (src-x, src-y) to (dest-x, dest-y) with width w and height h (Fig. 1). This method is used in XAA ScreenToScreenCopy function. But S3 GP hasn't mean to copy offscreen pixmaps in format presented on Fig. 2 to framebuffer, i. e. there is no way to write the pixmap's offset and pitch directly into GP registers to make subsequent copying. I looked up on the code of few other drivers where EXA is implemented (ati, trident, mga) -- all these chips have the possibility to write offset and pitch of pixmap into their GP. Although the method (by means of Pixel Transfer Register) exists to upload pixmap from the system memory to S3's offscreen memory in required format (Fig. 1) (I didn't try it), such offscreen memory organization will not be understandable to the EXA offscreen memory manager. Most probably this will follow to incorrect pixmap migration and overwriting previously uploaded pixmaps. The objection above sounds like the judgement to EXA support in S3 driver. No? Looks like no dice for EXA. Fixed pitches, no offsets... ouch. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Mod4 ignored?
Hello. I'm having a very strange problem with regards to the Mod4 key. Currently, it's mapped to the windows key: $ xmodmap -pm xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40), Alt_R (0x71), Meta_L (0x9c) mod2Num_Lock (0x4d) mod3 mod4Super_L (0x7f), Hyper_L (0x80) mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c) ~/.xmodmaprc: keycode 115 = Super_L keycode 116 = Super_R add Mod4 = Super_L add Mod4 = Super_R Unfortunately, I can't seem to get any wm to listen to Mod4. I can use the following in ~/.fluxbox/keys, for example: Mod4 Right :NextWorkspace Mod4 Left :PrevWorkspace ...pressing Mod4 + left or Mod4 + right does nothing. No key setting involving Mod4 does anything. xev shows the key event occuring (in other words, if I hold 'T', for example, and then tap the windows key, a few of the fields change for the 'T' key event - suggesting a modifier key is being pressed). Any ideas? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 1/2] kdrive: add protocol mouse option
On Wed, May 27, 2009 at 07:04:16PM +0200, Olivier Blin wrote:
Peter Hutterer peter.hutte...@who-t.net writes:
On Tue, May 26, 2009 at 03:30:08PM +0200, Olivier Blin wrote:
kdrive probes a lot of PS/2 protocols for the mouse device, which
makes the mouse unusable for some seconds after X startup.
This new protocol option allows forcing the mouse protocol.
It can be used this way:
Xfbdev -mouse mouse,,protocol=ps/2 -keybd keyboard
Signed-off-by: Olivier Blin bl...@mandriva.com
---
hw/kdrive/linux/mouse.c |4 +++-
hw/kdrive/src/kdrive.h |1 +
hw/kdrive/src/kinput.c |3 +++
3 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/hw/kdrive/linux/mouse.c b/hw/kdrive/linux/mouse.c
index 02214b3..253da26 100644
--- a/hw/kdrive/linux/mouse.c
+++ b/hw/kdrive/linux/mouse.c
@@ -961,7 +961,9 @@ MouseInit (KdPointerInfo *pi)
km = (Kmouse *) xalloc (sizeof (Kmouse));
if (km) {
km-iob.avail = km-iob.used = 0;
-MouseFirstProtocol(km, exps/2);
+MouseFirstProtocol(km, pi-force_protocol ? pi-force_protocol :
exps/2);
+if (pi-force_protocol)
+km-state = MouseWorking;
km-i_prot = 0;
km-tty = isatty (fd);
km-iob.fd = -1;
diff --git a/hw/kdrive/src/kdrive.h b/hw/kdrive/src/kdrive.h
index c60559a..c025144 100644
--- a/hw/kdrive/src/kdrive.h
+++ b/hw/kdrive/src/kdrive.h
@@ -220,6 +220,7 @@ struct _KdPointerInfo {
DeviceIntPtr dixdev;
char *name;
char *path;
+char *force_protocol;
InputOption *options;
int inputClass;
diff --git a/hw/kdrive/src/kinput.c b/hw/kdrive/src/kinput.c
index 0d216a9..5f82ba4 100644
--- a/hw/kdrive/src/kinput.c
+++ b/hw/kdrive/src/kinput.c
@@ -1166,6 +1166,8 @@ KdParsePointerOptions (KdPointerInfo *pi)
pi-transformCoordinates = FALSE;
else if (!strcasecmp (option-key, device))
pi-path = strdup(option-value);
+else if (!strcasecmp (option-key, protocol))
+pi-force_protocol = strdup(option-value);
else
ErrorF(Pointer option key (%s) of value (%s) not
assigned!\n,
option-key, option-value);
@@ -1186,6 +1188,7 @@ KdParsePointer (char *arg)
return NULL;
pi-emulateMiddleButton = kdEmulateMiddleButton;
pi-transformCoordinates = !kdRawPointerCoordinates;
+pi-force_protocol = NULL;
pi-nButtons = 5; /* XXX should not be hardcoded */
pi-inputClass = KD_MOUSE;
--
1.6.2.4
wouldn't it be better to name the option protocol instead of
force_protocol to reflect the cmdline option?
I used the force_ prefix mainly to indicate it is optional, but it's
ok to just name it protocol (note that device option and pi-path have
the same issue, if we want to be picky).
Do you want me to resend the patch using protocol as field name?
yes. I think it is the better option. We don't need to show in the name that
it's optional, it's common that an unset option defaults to some
auto-detected value.
force_protocol is IMO even a bit misleading here, it would indicate that
you're overriding or enforcing a protocol on the device even if the protocol
is not supported. When in fact I guess that by using a wrong protocol the
device simply won't work, right?
Either way, amend with s/force_protocol/protocol/ and we're all good.
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
Peter, Do you think that http://cgit.freedesktop.org/xorg/xserver/commit/?id=5e43cd28692bc05cac80f38b47104a26c0524385 can/should be backed out for the time being until an alternative solution to this matter becomes available, because with this change in place in the current server, there's no real way to debug popup menu callback code during a grab where the application and the debugger are on the same display. Regards, -- Dave Peter Hutterer wrote: On Tue, May 26, 2009 at 02:13:15PM +0100, Daniel Stone wrote: On Tue, May 26, 2009 at 01:17:15PM +1000, Peter Hutterer wrote: On Tue, May 26, 2009 at 11:56:58AM +1000, David Campbell wrote: By switching to a VT, did you mean pressing CTRL-ALT-number to switch to a virtual terminal? That doesn't work for me, due to the grab. Pressing those keystrokes is unresponsive, thus for a standalone system in a location where there are no other computers, it still appears that the only option in the situation of hitting a breakpoint during a grab, is to force a power down and reboot. VT switching only works as long as the grab is asynchronous, otherwise events are queued up on the device for replaying and never pass through the XKB paths that trigger this behaviour. We should probably fix this for XKB2 by keeping a 'last internal state' separate to the normal state, which takes into account all thawed events; does that sound sensible? Then we can define 'internal actions' which take the new state field into account, or just specify that all actions are thus processed before the device is thawed. The only reason why the event's arent processed in a frozen device is because the processInputProc is changed to EnqueueEvent which does nothing but stack the events into the queue. You could hook up the VT switching and Terminate_Server actions in there (the events need to be discarded or marked used though so thawing the device doesn't switch again). I don't think there's any need for XKB2 as such, it could be fixed in the current implementation. I'll leave that as an exercise to the reader though. Cheers, Peter ___ 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: Is there the possibility to support EXA for legacy S3 chips?
On Wed, May 27, 2009 at 6:20 PM, Ville Syrjälä syrj...@sci.fi wrote: On Wed, May 27, 2009 at 05:50:51PM -0400, Alex Deucher wrote: On Wed, May 27, 2009 at 5:09 PM, Evgeny M. Zubok evgeny.zu...@tochka.ru wrote: I have made the first attempt to implement basic `Copy' and `Solid' EXA functions in xf86-video-s3, but soon came to intention that EXA support is not possible. Is there mistake in my thinking below? S3's Graphic Processor (S3 GP) is able to copy areas only in terms of coordinates, i. e. it can copy rectangle from (src-x, src-y) to (dest-x, dest-y) with width w and height h (Fig. 1). This method is used in XAA ScreenToScreenCopy function. But S3 GP hasn't mean to copy offscreen pixmaps in format presented on Fig. 2 to framebuffer, i. e. there is no way to write the pixmap's offset and pitch directly into GP registers to make subsequent copying. I looked up on the code of few other drivers where EXA is implemented (ati, trident, mga) -- all these chips have the possibility to write offset and pitch of pixmap into their GP. Although the method (by means of Pixel Transfer Register) exists to upload pixmap from the system memory to S3's offscreen memory in required format (Fig. 1) (I didn't try it), such offscreen memory organization will not be understandable to the EXA offscreen memory manager. Most probably this will follow to incorrect pixmap migration and overwriting previously uploaded pixmaps. The objection above sounds like the judgement to EXA support in S3 driver. No? Looks like no dice for EXA. Fixed pitches, no offsets... ouch. Why wouldn't it work if you just allocate everything using the same pitch? Or does the allocator make some assumptions about the pitches the hardware can handle? The allocator doesn't support a fixed pitch, only pitch alignment. You could probably hack something together and disable offscreen pixmaps, but I don't think it would be worth the effort as you'd probably end up falling back in a lot of cases and the lack offscreen pixmaps would hurt performance. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On Wed, May 27, 2009 at 05:50:51PM -0400, Alex Deucher wrote: On Wed, May 27, 2009 at 5:09 PM, Evgeny M. Zubok evgeny.zu...@tochka.ru wrote: I have made the first attempt to implement basic `Copy' and `Solid' EXA functions in xf86-video-s3, but soon came to intention that EXA support is not possible. Is there mistake in my thinking below? S3's Graphic Processor (S3 GP) is able to copy areas only in terms of coordinates, i. e. it can copy rectangle from (src-x, src-y) to (dest-x, dest-y) with width w and height h (Fig. 1). This method is used in XAA ScreenToScreenCopy function. But S3 GP hasn't mean to copy offscreen pixmaps in format presented on Fig. 2 to framebuffer, i. e. there is no way to write the pixmap's offset and pitch directly into GP registers to make subsequent copying. I looked up on the code of few other drivers where EXA is implemented (ati, trident, mga) -- all these chips have the possibility to write offset and pitch of pixmap into their GP. Although the method (by means of Pixel Transfer Register) exists to upload pixmap from the system memory to S3's offscreen memory in required format (Fig. 1) (I didn't try it), such offscreen memory organization will not be understandable to the EXA offscreen memory manager. Most probably this will follow to incorrect pixmap migration and overwriting previously uploaded pixmaps. The objection above sounds like the judgement to EXA support in S3 driver. No? Looks like no dice for EXA. Fixed pitches, no offsets... ouch. Why wouldn't it work if you just allocate everything using the same pitch? Or does the allocator make some assumptions about the pitches the hardware can handle? -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On 2009/05/27 18:34 (GMT-0400) Alex Deucher composed: ...the lack offscreen pixmaps would hurt performance. I'm just an observer whose only real interest is in seeing to it that dropping of any legacy support is not done casually. I can only wonder if anyone using a 12 year old legacy chip has any interest in performance beyond just working at all. Surely best possible performance is a worthy goal, but does anyone running antique S3 expect anything more than adequately functional? -- A fool gives full vent to his anger, but a wise man keeps himself under control. Proverbs 29:11 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Thu, May 28, 2009 at 08:30:24AM +1000, David Campbell wrote: Do you think that http://cgit.freedesktop.org/xorg/xserver/commit/?id=5e43cd28692bc05cac80f38b47104a26c0524385 can/should be backed out for the time being until an alternative solution to this matter becomes available, because with this change in place in the current server, there's no real way to debug popup menu callback code during a grab where the application and the debugger are on the same display. I don't think backing this change out is a good idea for master. xf86ProcessActionEvent is a specific API that used to be called from the kbd driver only - and this code has been removed in favour of XKB processing. A grep on my xorg/ tree shows that none of the maintained input drivers use this API now. So right now, even bringing it back doesn't help you since the kbd driver doesn't call the API anyway, and evdev never has. Indeed, time is better spent fixing this correctly - as Daniel said with a new XKB action - and hooking this action up in the right places. Owen suggested that for Qt and GDK there's workarounds to enable debugging. They don't work for you? Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
From a performance pov an accelerated shadow framebuffer arrangement is probably much faster. Assuming it has some dma capability. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: up-arrow key not working again.
On Wed, May 27, 2009 at 03:55:07PM -0500, Robin Cook wrote: I have the AllowEmptyInput but not the AutoAddDevices. Section ServerFlags Option AllowEmptyInput false EndSection The two option were what I was told to put in there and it was working on the previous version with the patch. Oh. that'd explain it then. I'm suprised you don't get duplicate key events though. anyway. If AEI is off in the server, the server defaults to the xorg rules file (which is the one for the kbd driver). you still have AutoAddDevices on, so the device you actually see are the ones added by through HAL with the evdev driver. evdev has different keycodes than kbd, leading to the up/screenshot issue. if you remove the AEI option (or enable it, the default), the server defaults to the evdev ruleset (expecting devices to be added) and the problem is gone. Note that while you're at it, remove the keyboard section from your xorg.conf, it'll be ignored once AEI is on anyway. tbh, I can't even think of a scenario where AEI should be off but AutoAddDevices should be on. The reason why we see this configuration is that some (pre-released) X servers required it to get the evdev keycode issues sorted out. So please tell your friends that AEI off is not your friend at all. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-input-synaptics 1.1.2
One patch that should have made it into 1.1.1 but didn't. Jeremy's patch adds model-specific edges for appletouch touchpads in the same fashion as we already do for ALPS and synaptics pads. Jeremy Huddleston (1): Add model-specific edges for appletouch. Peter Hutterer (1): synaptics 1.1.2 git tag: xf86-input-synaptics-1.1.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.1.2.tar.bz2 MD5: c8fd6516f9636a3751e401e4b836e160 xf86-input-synaptics-1.1.2.tar.bz2 SHA1: ee3f643f3ac3738e1d7755b4d2ce171f018a5b94 xf86-input-synaptics-1.1.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.1.2.tar.gz MD5: 219703b16f97dc62f560f2040d674eae xf86-input-synaptics-1.1.2.tar.gz SHA1: 0bae836973636174bf0fc64d8aa5f79dcbbd1dc4 xf86-input-synaptics-1.1.2.tar.gz pgplxFC4pYoE5.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
Xavier Bestel wrote: The main benefit of a grab in the use of menus is that you will get the next event regardless of where it occurs. This is what makes the menu disappear when you click elsewhere. If the application didn't grab, the menu could only disappear by activating a menu item, or - assuming the application supports this - by clicking elsewhere in one of the application's windows. Just as a datapoint, AFAIK that's how Windows GUI toolkits work. They don't grab the whole display, thay just wait for events in their window. Windows isn't X. On Windows menus are a distinct class of GUI object, distinct from a Window. On X, a menu is just a window, and the application needs to use a grab if it wants to close the menu when a click occurs outside of the menu. Any suggestions on solving this feature through other means is appreciated (note that registering for events on every visible window doesn't count). Limiting events to the application windows doesn't seem that bad. That would mean that menus persist until you click in a window belonging to the application which created the menu. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
