init: environ_valid() does not accept dot in key

Bug #567068 reported by Peter Löfgren on 2010-04-20
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Scott James Remnant
upstart (Ubuntu)

Bug Description

Binary package hint: udev

Trying to configure my Logitech Marble for Lucid (amd64) as per
using udev rules. The rule is run, but fails with error

[13838.180329] usb 7-1: new low speed USB device using uhci_hcd and address 5
[13838.359037] usb 7-1: configuration #1 chosen from 1 choice
[13838.377529] input: Logitech USB Trackball as /devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0/input/input17
[13838.379229] generic-usb 0003:046D:C408.0008: input,hidraw3: USB HID v1.10 Mouse [Logitech USB Trackball] on usb-0000:00:1d.1-1/input0
upstart-udev-bridge[423] Env must be KEY=VALUE pairs

Now if I comment all x11_options like
the "Env must be KEY=VALUE pairs" error is gone when plugging in the Logitech mouse.
So I tried to instead removed the dot (.) in the notation above

and then it works, meaning it runs the rule without the KEY=VALUE error. But of course the mouse configuration does not take place.

In response to forum post
it was pointed to
saying that this wont be fixed. Instead use xorg.conf, but that is not available by default in Lucid, nor is Hal, and now this.

I'm not sure of this just needs a documentation update or a udev fix. But removing Hal, xorg.conf, and the udev rules does not work puts the user in limbo.

Frode Egeland (egeland) wrote :

This is really annoying - we had to use xorg.conf settings for Ubuntu 8.xx, a HAL fdi file for 9.xx and now although the help site says to use udev, it doesn't work!
Being told to once again use xorg.conf settings, after hal worked *perfectly*, seems so pointless.


If anyone can work out a solution that will make my Marble "just work", that'd be great.
I'll look at xorg.conf.d/ and see if I can figure out my old xorg.conf solution (which is long gone from my pc)...

Adamantios (adamand-cc) wrote :

I appended the following in /etc/X11/xorg.conf...

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
 Option "CorePointer"
 Option "Device" "/dev/input/mice"
 Option "Protocol" "auto"
        Option "Buttons" "5"
        Option "ButtonMapping" "1 8 3 2 9"
        Option "EmulateWheel" "true"
        Option "EmulateWheelTimeout" "300" # msec
        Option "EmulateWheelButton" "2"
        Option "YAxisMapping" "4 5"
        Option "XAxisMapping" "6 7"

...and now the X server logs:

(II) The server relies on udev to provide the list of input devices.
        If no devices become available, reconfigure udev or disable AutoAddDevices.
(WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
(WW) Disabling Configured Mouse

Adamantios (adamand-cc) wrote :

The attached xorg.conf worked for me. Adjust to your needs and please share your findings.

Guido I (guidoweb) wrote :

Hi everyone,
After some googling I found this excellent clarification on the issue:
(it's from fedora but applies exactly to ubuntu too, since both distros follow the same linux fs hierarchy guidelines)

Basically it says that:
/usr/lib/X11/xorg.conf.d/ is to be managed by the distro, and all changes will be overwritten
/etc/X11/xorg.conf.d/ can be used, but should be left for individual packages from repos
/etc/X11/xorg.conf plain old config file is still the way to go, with the difference that now you can set InputClasses :D

So you don't have to bother finding the correct /dev/input/event* number , you can just match by properties of the device.

I'm going to try it out now

Guido I (guidoweb) wrote :

Great, it worked

Pasting my conf

$ cat /etc/X11/xorg.conf
Section "InputClass"
 Identifier "Synaptics Custom Settings"
 MatchIsTouchpad "on"
 MatchDevicePath "/dev/input/event*"
 Driver "synaptics"
 Option "SHMConfig" "On"
 Option "TapButton1" "1"
 Option "CircularScrolling" "1"
 Option "CircScrollTrigger" "3" # Right edge
 Option "FastTaps" "1"
 Option "MaxDoubleTapTime" "120" # Make double-tap work faster for me
 Option "RTCornerButton" "2"
 Option "HorizEdgeScroll" "1"


Frode Egeland (egeland) wrote :

I just tried this, as /etc/X11/xorg.conf.d/marblemouse.conf:

Section "InputDevice"
 Identifier "Mouse0"
 Driver "mouse"
 Option "CorePointer"
 Option "Device" "/dev/input/mice"
 Option "Protocol" "auto"
        Option "Buttons" "5"
        Option "ButtonMapping" "1 8 3 2 9"
        Option "EmulateWheel" "true"
        Option "EmulateWheelTimeout" "300" # msec
        Option "EmulateWheelButton" "2"
        Option "YAxisMapping" "4 5"
        Option "XAxisMapping" "6 7"
### END OF FILE ###

This caused my X to lock up at the login screen, even after rebooting. I had to power off the machine, as I could not even Ctrl-Alt-F1 to get a text terminal login. After rebooting in recovery mode, I renamed the file (added "_disabled" to the name) and could use X once more.

As I have a Marble Mouse trackball, I'm hoping someone will figure out an actual working config, where I can use the buttons as follows:
Big Left: normal left mousebutton
Small Left: mousebutton 3, used to open new tabs in Firefox, or paste from the selection clipboard
Small Right + ball movement: scroll freely, vertically and horizontally
Big Right: normal right mousebutton

I could do all this with HAL, using this fdi, so hope I'll be able to do so again soon:
### START FILE ###
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
    <match key="info.product" string="Logitech USB Trackball">
      <merge key="input.x11_options.ButtonMapping" type="string">1 8 3 4 5 6 7 2 9</merge>
      <merge key="input.x11_options.EmulateWheel" type="string">true</merge>
      <merge key="input.x11_options.EmulateWheelButton" type="string">9</merge>
      <merge key="input.x11_options.ZAxisMapping" type="string">4 5</merge>
      <merge key="input.x11_options.XAxisMapping" type="string">6 7</merge>
      <merge key="input.x11_options.Emulate3Buttons" type="string">false</merge>
### END FILE ###

Frode Egeland (egeland) wrote :


Ignore the talk of "/etc/X11/xorg.conf.d/" - if I put a file in there, my USB keyboard fails to start, so I can't type anything.

Instead, add this to /etc/X11/xorg.conf:

Section "InputClass"
        Identifier "Marble Mouse"
        MatchProduct "Logitech USB Trackball"
        MatchIsPointer "on"
        MatchDevicePath "/dev/input/event*"
        Driver "evdev"
        Option "ButtonMapping" "1 8 3 4 5 6 7 2 9"
        Option "EmulateWheel" "true"
        Option "EmulateWheelButton" "9"
        Option "ZAxisMapping" "4 5"
        Option "XAxisMapping" "6 7"
        Option "Emulate3Buttons" "false"

Restart X (log out and back in, or reboot), and all should be well.

Ruslan (rulet3) wrote :

 Yes, but with this scrolling works only by right small button(it is good for left handed people).
How to make that scrolling was working with left small button?

Ruslan (rulet3) wrote :

 So, any ideas?

Andreas Raster (rakete) wrote :

Same problem here, trying to get my Marble Mouse working the way I had it working under 9.04.

These are the udev rules I am using:

ENV{ID_VENDOR}=="Logitech", \
    ENV{ID_MODEL}=="USB_Trackball", \
        ENV{x11_options.EmulateWheel}="true", \
        ENV{x11_options.EmulateWheelButton}="3", \
        ENV{x11_options.EmulateWheelTimeout}="200", \
        ENV{x11_options.YAxisMapping}="4 5", \
        ENV{x11_options.Emulate3Buttons}="false", \
        ENV{x11_options.Buttons}="9", \
        ENV{x11_options.ButtonMapping}="1 8 3 4 5 6 7 2 9"

syslog output:
May 18 19:26:33 capcom upstart-udev-bridge[517]: Env must be KEY=VALUE pairs

Frode Egeland (egeland) wrote :

Ruslan, try moving button mappings around (the "ButtonMapping" option).

Andreas, try my solution, see comment #7 in this bug.

Daniel Hahler (blueyed) wrote :

This regressed in the end of the Lucid development cycle.
See also for what stopped working for me.

Changed in udev (Ubuntu):
status: New → Triaged
importance: Undecided → High
tags: added: regression-release
Daniel Hahler (blueyed) wrote :

I do not get the error, but the following from "udevadm monitor -e" (at the end):
UDEV [1274463750.051633] add /devices/pci0000:00/0000:00:02.0/usb2/2-7/2-7:1.0/input/input6/event3 (input)
x11_options.ZAxisMapping=4 5
x11_options.ButtonMapping=1 2 2 4 5 6 7 3 8
DEVLINKS=/dev/char/13:67 /dev/input/by-id/usb-Kingsis_Peripherals_Evoluent_VerticalMouse_3-event-mouse /dev/input/by-path/pci-0000:00:02.0-usb-0:7:1.0-event-mouse

It seems like it gets applied, without errors, but the buttons do not change.

Martin Pitt (pitti) wrote :

This is actually a problem in upstart. environ_valid() doesn't take into account that key names can have dots in them. However, this should just be a cosmetical problem, and not related to the mouse actually working ( talks directly to udev, not through upstart).

affects: udev (Ubuntu) → upstart (Ubuntu)
Changed in upstart (Ubuntu):
importance: High → Low

Ah, I'd read the following from the shell guide:

     Variables set by the user must have a name consisting solely of alphabet‐
     ics, numerics, and underscores - the first of which must not be numeric.

But SUS says, elsewhere:

Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the '_' (underscore) from the characters defined in Portable Character Set and do not begin with a digit. Other characters may be permitted by an implementation; applications shall tolerate the presence of such names. Uppercase and lowercase letters shall retain their unique identities and shall not be folded together. The name space of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this name space without modifying the behavior of the standard utilities.

summary: - udev rules with dot in key fails with Env must be KEY=VALUE pairs
+ init: environ_valid() does not accept dot in key
Changed in upstart:
status: New → Triaged
importance: Undecided → Low
Changed in upstart (Ubuntu):
status: Triaged → Invalid

Moved upstream, since the bug is in the Upstart code

Scott James Remnant (scott) wrote :
Changed in upstart:
assignee: nobody → Scott James Remnant (scott)
milestone: none → 1.1
status: Triaged → Fix Committed
Changed in upstart:
status: Fix Committed → Fix Released
Changed in upstart (Ubuntu):
status: Invalid → New
importance: Low → Undecided
Steve Langasek (vorlon) wrote :

Upstart 1.3 included in Ubuntu oneiric.

Changed in upstart (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers