Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint

[Glynn Clements]

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 
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[ANNOUNCE] xf86-input-synaptics 1.1.2

[Peter Hutterer]

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: up-arrow key not working again.

[Peter Hutterer]

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

Re: Is there the possibility to support EXA for legacy S3 chips?

[Maarten Maathuis]

>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: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint

[Peter Hutterer]

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?

[Felix Miata]

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: Is there the possibility to support EXA for legacy S3 chips?

[Ville Syrjälä]

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  
> 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?

[Alex Deucher]

On Wed, May 27, 2009 at 6:20 PM, Ville Syrjälä  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  
>> 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: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint

[David Campbell]

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- 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: [PATCH 1/2] kdrive: add protocol mouse option

[Peter Hutterer]

On Wed, May 27, 2009 at 07:04:16PM +0200, Olivier Blin wrote:
> Peter Hutterer  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 
> >> ---
> >>  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

Mod4 ignored?

[xorg]

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: Is there the possibility to support EXA for legacy S3 chips?

[Alex Deucher]

On Wed, May 27, 2009 at 5:09 PM, Evgeny M. Zubok  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

Is there the possibility to support EXA for legacy S3 chips?

[Evgeny M. Zubok]

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: [PATCH 1/2] kdrive: add protocol mouse option

[Paul Menzel]

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 
> ---
>  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

Re: up-arrow key not working again.

[Robin Cook]

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: Mod4 ignored?

[xorg]

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: [xf86-video-ati] crash with latest code from git (possibly radeon-rewrite related)

[Alex Deucher]

On Wed, May 27, 2009 at 3:50 PM, Lowell Alleman
 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

[xf86-video-ati] crash with latest code from git (possibly radeon-rewrite related)

[Lowell Alleman]

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- SERR- http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH 2/2] kdrive: do not undef DEBUG macro in mouse driver

[Olivier Blin]

Peter Hutterer  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 
>> ---
>>  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

Re: [PATCH 1/2] kdrive: add protocol mouse option

[Olivier Blin]

Peter Hutterer  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 
>> ---
>>  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: up-arrow key not working again.

[ace102]

I had the same annoyance for a while on startup. If you're running Compiz
just reload the window manager. No problems lately with Gnome 2.26.1,
Xserver 1.6.99+, and Compiz 0.8.2.
  

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 had this problem before and someone pointed me to a patch for the
> previous xorg-server (1.5 I think) but I tried applying the patch and it
> applies but the compile fails.
> 
> Is there another patch that fixes this again?
> 
> Thanks
> CuZnDragon
> Robin Cook
> 
>  
> ___
> xorg mailing list
> xorg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-
Error:Success
-- 
View this message in context: 
http://www.nabble.com/up-arrow-key-not-working-again.-tp23733183p23746153.html
Sent from the Free Desktop - xorg mailing list archive at Nabble.com.

___
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

[Leonardo Boiko]

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: Xorg resolution with VGA Switch

[Aaron Plattner]

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

Xorg resolution with VGA Switch

[Aurélien PROVIN]

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  "XkbVariant""latin9"
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: up-arrow key not working again.

[dolphinling]

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

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: RandR support for Xvfb

[Alan Coopersmith]

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: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint

[Xavier Bestel]

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