headers
Stefan Monnier | 1 Mar 2012 02:25
Picon

Bug#661754: x11-xkb-utils: setxkbmap and xkbcomp settings do not apply to new keyboards

Package: x11-xkb-utils
Version: 7.6+4
Severity: important

Dear Maintainer,

My desktop can finally suspend and resume properly, which makes me very happy,
but let me discover a new obstacle: upon resume my keybard settings are lost
and I have to re-apply my xkbcomp setting every time.

The same can be seen without suspend&resume:

   % setxkbmap -model 'thinkpad(60)'
   % setxkbmap -query
   rules:      evdev
   model:      thinkpad(60)
   layout:     us
   % <unplug the (USB) keyboard, and plug it back in>
   % setxkbmap -query
   rules:      evdev
   model:      pc105
   layout:     us
   %

It seems that setxkbmap only affects the current InputDevice, whereas
I'd like to affect a whole InputClass, but I don't know how/where
to specify which inputs devices should be affected.
Where are the equivalent of xorg.conf's MatchIsKeyboard/MatchProduct/...?
Tho to tell you the truth, I don't need to distinguish input devices,
all I want is for my settings to apply to *all* keyboards (which
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cyril Brulebois | 1 Mar 2012 08:27
Picon
Favicon

Bug#661754: x11-xkb-utils: setxkbmap and xkbcomp settings do not apply to new keyboards

Stefan Monnier <monnier <at> iro.umontreal.ca> (29/02/2012):
> It seems that setxkbmap only affects the current InputDevice, whereas
> I'd like to affect a whole InputClass, but I don't know how/where
> to specify which inputs devices should be affected.
> Where are the equivalent of xorg.conf's MatchIsKeyboard/MatchProduct/...?
> Tho to tell you the truth, I don't need to distinguish input devices,
> all I want is for my settings to apply to *all* keyboards (which
> is only ever a single keyboard but which might get unplugged/replugged).

You might find that page useful then:
  http://x.debian.net/howto/configure-input.html

Mraw,
KiBi.
Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 Mar 2012 14:43
Picon

Bug#661754: x11-xkb-utils: setxkbmap and xkbcomp settings do not apply to new keyboards

>> It seems that setxkbmap only affects the current InputDevice, whereas
>> I'd like to affect a whole InputClass, but I don't know how/where
>> to specify which inputs devices should be affected.
>> Where are the equivalent of xorg.conf's MatchIsKeyboard/MatchProduct/...?
>> Tho to tell you the truth, I don't need to distinguish input devices,
>> all I want is for my settings to apply to *all* keyboards (which
>> is only ever a single keyboard but which might get unplugged/replugged).

> You might find that page useful then:
>   http://x.debian.net/howto/configure-input.html

But I can't find any information there about user-configuration: the
KBD config I'm installing is one specific to my particular preferences
and would not please the other users of this machine.
As evidenced by my question, I'm already aware of xorg.conf's InputClass
sections. 

        Stefan
Permalink | Reply | 0 comments |
headers
Jeffrey Sheinberg | 1 Mar 2012 17:41

Bug#661073: xorg: crashes running: emacs, gv, various web pages

On Tue, Feb 28, 2012 at 08:37:59PM +0100, Julien Cristau wrote:

> On Tue, Feb 28, 2012 at 12:52:12 -0500, Jeffrey Sheinberg wrote:
> 
> > The result - started up emacs, instant crash in the x-server.
> > 
> > Attached is the xorg log file from just after the above
> > crash - it was actually named /var/log/Xorg.0.log.old .
> > 
> You have kernel mode setting (kms) disabled.  Is this intentional?  Why?

Hi Julien,

1. Yes, this is intentional.

2. Because this was the easiest for me way to disable the framebuffer.

I don't like the framebuffer because I find it to be visually disturbing
when it scrolls.  I am working on finding a better way to disable the
framebuffer (modinfo for ttm,drm,drm_kms_helper,fbcon).

As far as KMS vs. UMS is concerned, they are both about the same for me,
ie, buggy.  It goes like this,

    Linux VC <--> Linux VC : always works

    Linux VC  --> X-server : always works for the first time only (xinit).

    X-server  --> Linux VC : always works
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien Cristau | 1 Mar 2012 20:10
Picon
Favicon

Bug#661754: x11-xkb-utils: setxkbmap and xkbcomp settings do not apply to new keyboards

On Wed, Feb 29, 2012 at 20:25:14 -0500, Stefan Monnier wrote:

> Where are the equivalent of xorg.conf's MatchIsKeyboard/MatchProduct/...?

gnome-settings-daemon.

Cheers,
Julien
Permalink | Reply | 6 comments |
headers
Tim | 1 Mar 2012 20:55
Favicon

Bug#661627: Avoid /tmp ?

As far as the short-term solution to this problem goes, how about
this (untested)?

if [ -e $SOCKET_DIR ] && [ ! -d $SOCKET_DIR ]; then
    mv $SOCKET_DIR $SOCKET_DIR.$$ || exit $?
fi
if [ ! -e $SOCKET_DIR ]; then
    mkdir $SOCKET_DIR || exit $?
    chown root:root $SOCKET_DIR
    chmod 1777 $SOCKET_DIR
fi

First move other types of files out of the way, as before (is this
even necessary?).  After that, we should have either no SOCKET_DIR or
a directory by that name we have created previously.  If it doesn't
exist as a directory, create it.

If something by that name suddenly appears in the race after our
second existence test, then fail, since someone is clearly doing some
hanky-panky. Otherwise, we should own the file and there shouldn't be
a risk.  I realize that the "|| exit $?" items are redundant given the
script's "set -e", but I like to see things explicit when security
matters, since some future maintainer might accidentally remove the
"set -e" for seemingly unrelated reasons.

Note that the "chown root:root $SOCKET_DIR" also seems redundant to me
(if we didn't already own it, we would have bigger problems, right?).

tim
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien Cristau | 1 Mar 2012 21:16
Picon
Favicon

Bug#661627: Avoid /tmp ?

On Thu, Mar  1, 2012 at 11:55:29 -0800, Tim wrote:

> As far as the short-term solution to this problem goes, how about
> this (untested)?
> 
> 
> if [ -e $SOCKET_DIR ] && [ ! -d $SOCKET_DIR ]; then
>     mv $SOCKET_DIR $SOCKET_DIR.$$ || exit $?
> fi
> if [ ! -e $SOCKET_DIR ]; then
>     mkdir $SOCKET_DIR || exit $?
>     chown root:root $SOCKET_DIR
>     chmod 1777 $SOCKET_DIR
> fi
> 
So far I have this:

diff --git a/debian/x11-common.init b/debian/x11-common.init
index 34835ac..71f9fd5 100644
--- a/debian/x11-common.init
+++ b/debian/x11-common.init
 <at>  <at>  -30,10 +30,12  <at>  <at>  set_up_socket_dir () {
   if [ "$VERBOSE" != no ]; then
     log_begin_msg "Setting up X server socket directory $SOCKET_DIR..."
   fi
-  if [ -e $SOCKET_DIR ] && [ ! -d $SOCKET_DIR ]; then
-    mv $SOCKET_DIR $SOCKET_DIR.$$
+  # if $SOCKET_DIR exists and isn't a directory, move it aside
+  if [ -e $SOCKET_DIR ] && ! [ -d $SOCKET_DIR ] || [ -h $SOCKET_DIR ]; then
+    mv $SOCKET_DIR "$(mktemp -d $SOCKET_DIR.XXXXXX)"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim | 1 Mar 2012 21:39
Favicon

Bug#661627: Avoid /tmp ?


Hi Julien,

> > As far as the short-term solution to this problem goes, how about
> > this (untested)?
> > 
> > 
> > if [ -e $SOCKET_DIR ] && [ ! -d $SOCKET_DIR ]; then
> >     mv $SOCKET_DIR $SOCKET_DIR.$$ || exit $?
> > fi
> > if [ ! -e $SOCKET_DIR ]; then
> >     mkdir $SOCKET_DIR || exit $?
> >     chown root:root $SOCKET_DIR
> >     chmod 1777 $SOCKET_DIR
> > fi
> > 
> So far I have this:
> 
> diff --git a/debian/x11-common.init b/debian/x11-common.init
> index 34835ac..71f9fd5 100644
> --- a/debian/x11-common.init
> +++ b/debian/x11-common.init
>  <at>  <at>  -30,10 +30,12  <at>  <at>  set_up_socket_dir () {
>    if [ "$VERBOSE" != no ]; then
>      log_begin_msg "Setting up X server socket directory $SOCKET_DIR..."
>    fi
> -  if [ -e $SOCKET_DIR ] && [ ! -d $SOCKET_DIR ]; then
> -    mv $SOCKET_DIR $SOCKET_DIR.$$
> +  # if $SOCKET_DIR exists and isn't a directory, move it aside
> +  if [ -e $SOCKET_DIR ] && ! [ -d $SOCKET_DIR ] || [ -h $SOCKET_DIR ]; then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 Mar 2012 20:31
Picon

Bug#661754: x11-xkb-utils: setxkbmap and xkbcomp settings do not apply to new keyboards

>> Where are the equivalent of xorg.conf's MatchIsKeyboard/MatchProduct/...?
> gnome-settings-daemon.

Can you point me to some documentation as to how I'd use
gnome-settings-daemon to setup a particular XKB config on all current
and future keyboards?
(maybe a relevant detail of that XKB config: it uses a `symbols' file from
my home directory rather than limiting itself to the bundled set of
symbols)?

        Stefan
Permalink | Reply | 0 comments |
headers
Julien Cristau | 1 Mar 2012 21:48
Picon
Favicon

Bug#661627: Avoid /tmp ?

On Thu, Mar  1, 2012 at 12:39:41 -0800, Tim wrote:

> I think there is still a race in your version in the lines which look
> like:
> 
> > +  mkdir $ICE_DIR 2>/dev/null || [ -d $ICE_DIR ] && ! [ -h $ICE_DIR ]
> 
> mkdir will fail if the file already exists for any reason.  After
> mkdir fails, it is possible that another process will be able to run
> and remove/create new versions of the path with different properties
> after your tests run.
> 
doh.  You're right, of course.

[...]
> > > Note that the "chown root:root $SOCKET_DIR" also seems redundant to me
> > > (if we didn't already own it, we would have bigger problems, right?).
> > > 
> > I guess it protects against some user doing mkdir /tmp/.X11-unix before
> > this runs (which probably means before the package is installed, so it's
> > not like this is a very likely race) and then owning the directory.
> 
> Oh, right, duh.  Well, the dir is created every time the box boots,
> since /tmp is cleared, so it is needed for sure.
> 
/etc/init.d/x11-common on boot should run before any unprivileged user
has a chance to do anything (it's in rcS.d, and depends only on
$local_fs), so it's less of a problem than initial package installation
AFAICT.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane