Lenovo Y550 - touch buttons "OneKey Theater" and "Dolby" not work

[RussianNeuroMancer]

I have a Lenovo Y550-4CWI laptop, but as I know this issue releated to any Lenovo Yxx0 laptop.
"OneKey Theater" and "Dobly" touch-buttons not work. This buttons not recognized by xev.
So I understand, Linux not have applications for this buttons, but I want use this buttons for other applications, and can't do it.
Additional information: this touch-buttons must work like a switch - enable/disable assigned functions.

[Warp-spam+fdo (warp-spam+fdo)]

This is on my todo list for the xserver 1.4 release, however due to protocol issues it may not happen.

It most definitely will never be supported in the 1.1 branch.

It will definitely not happen instantly.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

I know it's a difficult problem, but lists blogs & wikis are littered with users trying to figure where in the kernel -> xorg input -> xkb bermuda triangle from hell their keys are lost (and then they pile on workarounds that make the situation worse more often than not)

I hope it will make 1.4. This is a major problems that has needed urgent fixing for a long time.

[Daniel Stone (daniels)]

by far the easiest way to fix this, is to bump the protocol to x12. that should give you an idea of how hard the alternatives are.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

despair :(

And yet it is getting impossible to buy plain input hardware without extended keys, and once users have them they expect them to work, so the house is burning today

Is x12 realistic for xserver 1.4?

[Daniel Stone (daniels)]

well, we've been on x11 since 1985, so it's not feasible to go to x12 in the next two months, no.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

Ok.

I just hope then you're planning x12 inside xorg today then, because Linux is moving on the desktop space now (with Ubuntu and friends), and it won't be possible to ignore input problems anymore soon. We're not talking of ssh-accessed servers now.

[Daniel Stone (daniels)]

thanks for your concern, but you're talking to the people who are gradually rewriting the input code, and have, in fact, rewritten basically all of it (bar xkb -- which is in the middle of being rewritten itself) between three of us, in the past year. any contribution you may want to make is more than welcome, but failing that, you'll just have to be patient.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

I didn't want to seem disrespectful or anything like that. (If I was I apologize)

It's just all this x12 talk feels like even if the input code was written soon it would be delayed a long time before the other xorg maintainers agree on what to include in the protocol bump. So I was wondering if x12 was discussed @xorg so the excellent input code you fine people will surely write in the near future won't be delayed by x12 discussions.

(I also wanted to know if it was reasonable to plan xkb-config patching for my hardware, or if I was likely to use something else by the time evdev is fixed.)

[Alan Coopersmith (alan-coopersmith)]

Do you really need more than 255 keycodes at the same time? If not,
remapping keycodes > 255 to values < 255 should work with the existing
protocol (though I have no idea how hard it would be to do this mapping
in xevdev, since I've never looked at it).

As for X12 planning, the transition will be painful enough, we don't want
to do it more than once this decade, so we're in the stage of gathering up
all the things that need to be changed to get them all at once - see:
http://wiki.x.org/wiki/Development/X12

[Daniel Stone (daniels)]

unfortunately, xkb makes this mind-smashingly hard, but if anyone wants to code keycode compression into xkbcomp, feel free. (hint: don't start with the existing codebase.)

[Daniel Stone (daniels)]

(as an addendum, you'd need a way of hinting xkbcomp as to which keycodes to preserve, presumably by testing the EV_KEY bits. evdev needs a complete map; we don't know which keycodes will be needed until we've opened the device.)

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

Add to this hotplug fun, when a new device that uses keys discarted to make place for something else can be inserted at any time.

No remapping is a requirement if you want to support new input hardware by default. To have generic support you need to declare every known extended keycode, so devices the user plug in (which use any subset of those) just work. As hardware manufacturers are real good at finding new extended keys and coming up with new input devices the 255 limit has been passed some time ago. Any form of reduction to 255 codes only results in key collisions with some input device sets.

Current remapping only works for configs customized for a particular device set, where you know the specific keycode set used. Also, every remapping requires a customized set of xkeyboard-config localized layouts. Since the result can not be safely shared, that's a labour-intensive enthusiast-only solution.

[Daniel Stone (daniels)]

(In reply to comment #12)
> Add to this hotplug fun, when a new device that uses keys discarted to make
> place for something else can be inserted at any time.

yes, that's fine. new devices are inserted individually, with completely different maps. the keymap of one device has absolutely no effect on the other: you can have three keyboards: one with a us layout, one with german, and one with french. actually, you can have 127 keyboards with different layouts.

> No remapping is a requirement if you want to support new input hardware by
> default. To have generic support you need to declare every known extended
> keycode, so devices the user plug in (which use any subset of those) just work.

that's what i said.

> As hardware manufacturers are real good at finding new extended keys and coming
> up with new input devices the 255 limit has been passed some time ago. Any form
> of reduction to 255 codes only results in key collisions with some input device
> sets.

you reduce per device. evdev lets you query which keys your keyboard is capable of producing, so unless you have a device with more than 255 physical keys, you're doing okay.

> Current remapping only works for configs customized for a particular device
> set, where you know the specific keycode set used. Also, every remapping
> requires a customized set of xkeyboard-config localized layouts. Since the
> result can not be safely shared, that's a labour-intensive enthusiast-only
> solution.

i'm not sure what you're trying to say here, other than manufacturers should make it possible for us to have any clue what the keyboard is automatically. right now, there are very, very, very few keyboards which actually give us enough information to set up a proper map per default.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

(In reply to comment #13)

> you reduce per device. evdev lets you query which keys your keyboard is
> capable of producing, so unless you have a device with more than 255 physical
> keys, you're doing okay.

But if you have device1 with extended key A, and device2 with extended key B, you still need to assign A & B different codes if you want A & B to have different effects on apps (that to not care where A & B are coming from)

To put stuff in perspective :

1. I have a bog-standard MS keyboard (ergo 4000). I count ~ 33 additional keys on it (not all exported via evdev yet, but they should be) 105 + 33 = 138 keys

2. I have an harmony universal remote. I will plug it in evdev someday. I count 47 keys that send an IR signal (actual number is higher, as the keys are modal and send different signals depending on the remote mode) 138 + 47 = 185 (most of the keys have different effects than the keyboard on and would be mapped to XF86Foo)

3. I've seen an xorg log yesterday with a mouse declaring ~ 30 buttons (most of which will be mapped to specific evdev codes) 185 + 30 = 215

That's awfully close to the 255 limit. Without even going to MPX and having several keyboards with different extended keys set on them

[Daniel Stone (daniels)]

(In reply to comment #14)
> (In reply to comment #13)
> > you reduce per device. evdev lets you query which keys your keyboard is
> > capable of producing, so unless you have a device with more than 255 physical
> > keys, you're doing okay.
>
> But if you have device1 with extended key A, and device2 with extended key B,
> you still need to assign A & B different codes if you want A & B to have
> different effects on apps (that to not care where A & B are coming from)

no, not really true. if you're typing on two different keyboards, then the core map gets pivoted every time the active device changes. anyhow, any toolkit not dealing with multiple devices separately is always going to have suboptimal behaviour. any app not using a toolkit is always going to have suboptimal behaviour.

> To put stuff in perspective :
>
> 1. I have a bog-standard MS keyboard (ergo 4000). I count ~ 33 additional keys
> on it (not all exported via evdev yet, but they should be) 105 + 33 = 138 keys
>
> 2. I have an harmony universal remote. I will plug it in evdev someday. I count
> 47 keys that send an IR signal (actual number is higher, as the keys are modal
> and send different signals depending on the remote mode) 138 + 47 = 185 (most
> of the keys have different effects than the keyboard on and would be mapped to
> XF86Foo)

no, you're still on device a: 138, and device b: 47.

> 3. I've seen an xorg log yesterday with a mouse declaring ~ 30 buttons (most of
> which will be mapped to specific evdev codes) 185 + 30 = 215

device a: 138, device b: 47, device c: 30.

> That's awfully close to the 255 limit. Without even going to MPX and having
> several keyboards with different extended keys set on them

i don't know what mpx has to do with multiple keyboards with multiple keymaps, since that can be done today.

you're still missing the point that we don't need to compress every device map into one map that covers every single keyboard plugged into the system. this is _not_ the case. really.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

Ok. Does compression need x12 too? or can it happen say this year?

[Daniel Stone (daniels)]

it's possible for someone to do it, yes. but it's not a small amount of work.

[Stanislav Brabec (sbrabec-suse)]

Two ideas, how to accept keycodes > 255 it backward compatible. All of them are ugly hacks, but may be accepted in X11 line:

1) evdev driver will query kernel for all available keys on all configured keyboards, then it will create table of false one-byte keysyms. In correspondence to them it will also write temporary xkb keycodes/evdev table.

2) X will accept keycodes > 255 internally, but in protocol level it will provide correct keysym with possibly incorrect keycode.

For both ugly hack is valid following limitation: Most applications read only keysym, the rest will break.

[Daniel Stone (daniels)]

(In reply to comment #18)
> 1) evdev driver will query kernel for all available keys on all configured
> keyboards, then it will create table of false one-byte keysyms. In
> correspondence to them it will also write temporary xkb keycodes/evdev table.

That only works if you have less than 255 possible keys.

> 2) X will accept keycodes > 255 internally, but in protocol level it will
> provide correct keysym with possibly incorrect keycode.
>
> For both ugly hack is valid following limitation: Most applications read only
> keysym, the rest will break.

The keysym is not sent with the event. Only the keycode is sent, and the applications keep a keycode/keysym mapping table. Having two mappings and switching between them will almost certainly break grabs, as well.

[Stanislav Brabec (sbrabec-suse)]

> That only works if you have less than 255 possible keys.

Yes. That can only work if you have less than 255 actual keys. You can still have more possible kernel key codes and assign X keycodes dynamically for actually existing keys. It can work, if only xkb will use keycodes directly and you will modify xkb table.

> The keysym is not sent with the event.

It means that xkb is completely in user level, isn't it?

There is a third ugly hack method inspired by "Extended MEDIUMRAW Mode" in Linux kernel. I guess that this one can be used to transfer keycodes without breaking protocol compatibility, but it will introduce need to modify input handling:

3) Use virtual key sequences to transfer more data:

Define say 17 reserved keys in the range < 256 - one ExtraEscape and sixteen ExtraData0-ExtraDataF.

Process keypresses in the following way:

- If the input keycode is from range 0-255 (except these 17 keys), handle it in a standard way.

- If the input keycode is outside this range, send it as a sequence of more keycodes: Each event can represent 4 bits, 4 events will create all 16 bits.

- These four events may be release only. If you allow press events as well, then it will need no ExtraEscape.

This method will still break applications waiting for "single press/release of any key".

[Stanislav Brabec (utx)]

Another idea, how to transfer characters > 255 through X11:

- Reserve say two modifiers for high keycodes (say ExtMod0, ExtMod1). Each extmod will add 1 bit.
- Programs using old byte-wide communication will get keypress as e. g. as ExtMod_combination+any_key_1-266
- Programs using new wide Xlib calls will get real keypresses (which can be sent in parallel with "compatible" way, or server and client can handshake about using this new way).

With 2 reserved modifiers we can transfer at least 956 keycodes, which seems to be sufficient in next few years.

[Daniel Stone (daniels)]

*** Bug 13203 has been marked as a duplicate of this bug. ***

[Daniel Stone (daniels)]

*** Bug 14843 has been marked as a duplicate of this bug. ***

[Stanislav Brabec (sbrabec-suse)]

Yet another idea, how to make it possible for X11: X Keycode Extension.

It would need patched of libX11 and server code on both sides. If X Keycode Extension will be present on both server and client, then wide keycodes will be transfered via extension. If not, low keycodes will be tranferred via standard X keyboard events, high keycodes will use "random" translation or they will be lost.

[Paul de Vrieze (pauldv)]

What are the possibilities of using a synthetic keyboard for this? This keyboard could just remove the most significant bit, and map the right keycodes.

[Daniel Stone (daniels)]

(In reply to comment #24)
> Yet another idea, how to make it possible for X11: X Keycode Extension.
>
> It would need patched of libX11 and server code on both sides. If X Keycode
> Extension will be present on both server and client, then wide keycodes will be
> transfered via extension. If not, low keycodes will be tranferred via standard
> X keyboard events, high keycodes will use "random" translation or they will be
> lost.

Given that this requires updates to XKB and Xi as well as the API and ABI of a lot of libraries, it's a lot easier for it to just be Xi 2/3 and XKB 2.

[Daniel Stone (daniels)]

(In reply to comment #25)
> What are the possibilities of using a synthetic keyboard for this? This
> keyboard could just remove the most significant bit, and map the right
> keycodes.

Unfortunately no, because this would break apps anyway, as no-one does the right thing of recalculating their keysym -> keycode tables for grabs when the map changes. So might as well just be Xi 2/3 and XKB 2.

[Daniel Stone (daniels)]

*** Bug 14078 has been marked as a duplicate of this bug. ***

[Daniel Stone (daniels)]

fwiw, xi 2 will be released with xserver 1.7 in mid-2009.

[Stanislav Brabec (sbrabec-suse)]

As this problem is going to be resolved, we should start think about getting correct translation between kernel and X.

Proposed patch for the old keyboard driver to pass keycodes 128-16383 (128-255 with old Xi) using "Extended MEDIUMRAW" encapsulation: bug 11545

Keyboard mapping project page:
http://fedoraproject.org/wiki/SIGs/Laptop/HotKeys

Mapping work-in-progress. One table and set of scripts providing all needed tables. Some keys still need discussion.

* Proposed mapping table between kernel and X: http://pack.suse.cz/sbrabec/keyboards/input_linux_map_fixed.txt

* Proposed logical categories of keys (to help understanding them): http://pack.suse.cz/sbrabec/keyboards/keymap_editor/keys.txt

* Scancode scripts for kernel (generated from X symbols/inet and table above): http://pack.suse.cz/sbrabec/keyboards/scancode_tables/

* Proposed code snippet to evdev_key.c driver (generated from the table above): http://pack.suse.cz/sbrabec/keyboards/evdev_key_c_table.txt

* Proposed X keycodes/evdev for evdev driver (generated from the table above): http://pack.suse.cz/sbrabec/keyboards/keycodes_evdev

* Proposed common extended basic keymap for X: http://pack.suse.cz/sbrabec/keyboards/symbols_evdev

* Proposed X keycodes/inet for RAW and SOFTRAW drivers (generated from X symbols/inet and table above): http://pack.suse.cz/sbrabec/keyboards/keycodes_inet

Things to discuss are marked with FIXME (X=X) (K=kernel)). It seems that several key codes in kernel are incorrect, and in X there are several duplicate codes.

Vojtech Pavlik provided a several banana boxes of obscure keyboards to me, so I am using the same source as he had 11 years ago for kernel.

[Peter Hutterer (peter-hutterer)]

(In reply to comment #30)
> Proposed patch for the old keyboard driver to pass keycodes 128-16383 (128-255
> with old Xi) using "Extended MEDIUMRAW" encapsulation: bug 11545

I'm not sure that we'd want to extend the kbd driver. evdev is the better vehicle for this, and maybe this puts enough pressure on other OS to provide an evdev-like input system.

> * Proposed code snippet to evdev_key.c driver (generated from the table above):
> http://pack.suse.cz/sbrabec/keyboards/evdev_key_c_table.txt

this table is ifdef'd out if you're compiling against the server past 1.6. so this part not needed.

[Stanislav Brabec (sbrabec-suse)]

For kdrive, the patch is important. Many embedded platforms still use old keyboard driver in MEDIUMRAW mode as a default and this patch extends key code range from 0-127 to 0-255. The kdrive patch is used in distributions derived from OpenEmbedded for several years.

"Extended MEDIUMRAW" mode should be superseded by evdev in the standard Xorg server. MEDIUMRAW mode is not used there for ~10 years and the code may be simplified by dropping its support at all as an alternative to "MEDIUMRAW -> Extended MEDIUMRAW" patch.

[Dakkar-thenautilus (dakkar-thenautilus)]

I realize I'm coming in pretty late to this bug, but I actually wrote a work-around (I won't presume to call it a "solution", I know it's a hack) to the evdev code that "work for me".

You can see it at http://www.thenautilus.net/cgit/xf86-input-evdev/?h=code-remap

Summary: I added a new option, "evdev_key_remap", whose value should be a string of the format "$evdev_code = $x11_code ..." (a sequence of "assignments" separated by spaces). The PostKbdEvent function will then use those "assignments" to remap the codes coming from the device.

I have it running on my machine, with the new option set to "464=118", so that the "Fn" key in my Apple Aluminium keyboard is treated as the "Ins" key that occupies that space on most other keyboards.

Hope this helps.

[Andre Klapper (a9016009)]

(Maemo downstream ticket at https://bugs.maemo.org/show_bug.cgi?id=3021 .)

[Peter Hutterer (peter-hutterer)]

*** Bug 23538 has been marked as a duplicate of this bug. ***

[Julien Cristau (jcristau)]

*** Bug 26876 has been marked as a duplicate of this bug. ***

[RussianNeuroMancer (russianneuromancer)]

I have a Lenovo Y550-4CWI laptop, but as I know this issue releated to any Yxx0 laptop.
"OneKey Theater" and "Dobly" touch-buttons not work. This buttons not recognized by xev.
So I understand, Linux not have applications for this buttons, but I want use this buttons for other applications, and can't do it.
Additional information: this touch-buttons must work like a switch - enable/disable assigned functions.

[RussianNeuroMancer (russianneuromancer)]

I tried use tp-smapi-dkms for detect this buttons, but it's not work for me with error: No such device.

[RussianNeuroMancer (russianneuromancer)]

https://bugzilla.kernel.org/show_bug.cgi?id=16001

[Maxim Levitsky (maximlevitsky)]

ping

[Julien Cristau (jcristau)]

> --- Comment #37 from <email address hidden> 2010-07-03 18:52:41 PDT ---
> ping

pong. did you want to say something?

[Maxim Levitsky (maximlevitsky)]

I mean, is there any update on this?

[Andre Klapper (a9016009)]

(In reply to comment #39)
> I mean, is there any update on this?

No.

[RussianNeuroMancer (russianneuromancer)]

After BIOS update (version 33) there is two difference:
1. This buttons not work as switch anymore - just like typical buttons. After I
press one of this two buttons they light brighter few seconds.
2. I check dmesg:

Reaction to "OneKey Theater" button:
[ 6623.518552] atkbd.c: Use 'setkeycodes e015 <keycode>' to make it known.
[ 6627.273239] atkbd.c: Unknown key pressed (translated set 2, code 0xa3 on
isa0060/serio0).

Reaction to "Dolby":
[ 6627.273242] atkbd.c: Use 'setkeycodes e023 <keycode>' to make it known.
[ 6627.280194] atkbd.c: Unknown key released (translated set 2, code 0xa3 on
isa0060/serio0).

[Martin Pitt (pitti)]

Thanks. So the dmesg messages show me the keycodes. Can you now please give me the output of

  grep -r . /sys/class/dmi/id

so that I can write a complete rule for your particular system? Thanks!

[RussianNeuroMancer (russianneuromancer)]

Output is attached.

Maybe it's possible to assign "OneKey Theater" button to video player and "Dolby" button to system sound settings?
I thinks it's give good user experience if this two buttons work in this way out of the box.

[Maxim Levitsky (maximlevitsky)]

Why not at least for now let the evdev to send extended keys as a say Mod5+key?
I mean this is real very nasty problem for users with IR remotes, and formal support for which will land in 2.6.36.

[Peter Hutterer (peter-hutterer)]

any "for now" solution that ends up being used is hard to change later on
without breaking clients. And we're generally trying to avoid that.

besides, evdev doesn't really have a notion of Mod5, it may be reassigned at
any time and the driver wouldn't even notice. while that's not common it
cannot be ruled out and would just causes more issues

[RussianNeuroMancer (russianneuromancer)]

> system sound settings
Here I mean sound settings both of Ubuntu and Kubuntu. It is possible?

[Martin Pitt (pitti)]

Lenovos are a bit special, since some of them have the media keys on a separate input device. Can you please copy this file to /lib/udev/rules.d/, reboot, and check if they keys work now? I assigned them to KEY_MEDIA and KEY_SOUND, which are both recognized by X.org (so you can use them in both Ubuntu and KDE), but I'm not sure whether they'll do anything out of the box. But with this you should at least be able to assign them to anything in they keyboard shortcut preferences. Thanks!

[RussianNeuroMancer (russianneuromancer)]

Thanks!
Looks like by default this KEY_MEDIA and KEY_SOUND not assigned to anything (at least in KDE).
For testing I try to assign KEY_MEDIA to SMPlayer and KEY_SOUND to PulseAudio Settings using Menu Editor.
KEY_MEDIA is recognized by Menu Editor and I sucsesfully assign it to SMPlayer, but KEY_SOUND not recognized by Menu Editor at all.
Okay, then there is a two another problems:
1. KEY_MEDIA not have default reaction in KDE. I will test today daily Ubuntu Maverick build for check Gnome.
2. KEY_SOUND not work in KDE (but maybe it's can be Qt problem, like with additional mouse buttons). I must report it to KDE bugtracker?

[Martin Pitt (pitti)]

Could you please check with "xev" whether you get correct key codes when you press these keys? That's as far as we can go with udev, i. e. provide correct key codes. Interpreting them is a matter of KDE/GNOME, so those should become KDE bugs, right.

Thanks!

[RussianNeuroMancer (russianneuromancer)]

XF86AudioMedia for OneKey Theater button. It's correct? There is no XF86VideoMedia code? Maybe I must request add new code for video buttons?

But with "Dolby" button problem:

KeyPress event, serial 34, synthetic NO, window 0x5400001,
    root 0x15d, subw 0x0, time 3374348, (640,389), root:(642,412),
    state 0x0, keycode 221 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x5400001,
    root 0x15d, subw 0x0, time 3374368, (640,389), root:(642,412),
    state 0x0, keycode 221 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Then it's not KDE/Qt bug yet, but problem with assign button to key-code.

[RussianNeuroMancer (russianneuromancer)]

In Ubuntu KEY_MEDIA expectedly launch Rhythmbox, instead of Totem.
Looks like rename key-code KEY_MEDIA and add another key-code for video application and also to X.org is necessary. How this problem can be solved in the right way?

[RussianNeuroMancer (russianneuromancer)]

I look at /usr/include/linux/input.h and found there is KEY_VIDEO key-code available. Maybe better to assign OneKey Theater to this key-code? But anyway how X.org will handle KEY_VIDEO without XF86VideoMedia?

[RussianNeuroMancer (russianneuromancer)]

> I mean this is real very nasty problem for users with IR remotes
Also there is a big problem with hardware hotkeys on laptops. Many laptops have hardware buttons for launch audio and video players, but because of this bug at this moment not possible to assign this buttons to suitable KEY_AUDIO and KEY_VIDEO scancodes.

[Martin Pitt (pitti)]

> XF86AudioMedia for OneKey Theater button. It's correct?

Yes, I'm afraid there is no other keycode in /usr/include/linux/input.h which is more appropriate and < 256. There are a few >= 256, but X cannot deal with them, so they wouldn't work at all then. In particular, KEY_VIDEO is 0x189.

[Martin Pitt (pitti)]

As for the "sound" key assignment, this indeed doesn't seem to work in X. So we could assign it to KEY_PLAY instead. This is done by attached file.

[RussianNeuroMancer (russianneuromancer)]

> So we could assign it to KEY_PLAY instead. This is done by attached file.
Thanks for updated keymap rules, I'll test it later today.

> There are a few >= 256, but X cannot deal with them, so they wouldn't work at all then.
> As for the "sound" key assignment, this indeed doesn't seem to work in X.
Sad to hear it. Hope it's will be solved soon.

[RussianNeuroMancer (russianneuromancer)]

Thanks, Martin!
Both of buttons now work.

[Martin Pitt (pitti)]

Thanks for testing! Committed to upstream git.

[Launchpad Janitor (janitor)]

This bug was fixed in the package udev - 162-2

---------------
udev (162-2) maverick; urgency=low

  * Merge bug fixes from trunk:
    - scsi_id: export target port group, for ALUA support
    - scsi_id: Fix compiler warnings
    - gudev: Deliver ::uevent signal in the thread-default main loop. This
      makes it possible to actually use the library in a multi-threaded
      application.
    - keymap: Add Lenovo Y550 (LP: #543065)
    - gudev: add a few annotations that newer gobject-introspection versions
      demand
    - Clarify WAIT_FOR documentation
    - Fix various syntax errors in rules
    - Add automatic rules syntax check
 -- Martin Pitt <email address hidden> Tue, 21 Sep 2010 13:28:09 +0200

[Brianm-thomasville (brianm-thomasville)]

>>> http://tusis.ru

- There is no reason to feel depressed if you, like so many other men today, have hit the rough spot of your sexual life when you cannot seem to be performing as well as you used to do. Your agitation and frustration are easily understood, and still you should know that with the modern development of worldwide pharmacological industries it is but natural that there is bound to be a solution for your own needs when it comes down to solving your erectile dysfunction problems.

- We suggest you getting erectile dysfunction drugs from our online drugstore cheaply, easily and without much to-do. You will always be taken care of and attended to with extreme care, and you will have the possibility of choosing from a wide range of erectile dysfunction products to find a solution that will best suit your particular needs.

- The whole world puts great trust in those famous diamond shaped pills, and if you are not an exception we would like to revise some basic points that speak in favor of putting your male health in the hands of those magical tablets.
Firstly, there is no need for regular therapy � those blue pills have to be taken directly before the planned sexual contact, and extra convenience shines through when you come to realize that the pills will not start working unless sufficient sexual stimulation is provided.

- Secondly, this erectile dysfunction solution is known for its extremely low adverse side effects profile, which makes it available for all age groups of patients. Besides, it really does not matter how old you are when it goes about taking erectile dysfunction pills � just make sure that you do not overdose, and they will work for you at their best!

- Finally, those fabulous pills do not only provide you with stable erection that can be maintained for as long as you need it � they also help you to achieve unheard sensitivity during the sexual act as well as make your genitals look much more sizey!

- Think of all those benefits of taking erectile dysfunction pills and the effect you can produce on your loved one � and do not hesitate to make your order and / or refills right away!

--- > http://tusis.ru < ---

 _V______C________L
 ___I_______I_______E
 _____A_______A_______V
 _______G_______L_______I
 _________R_______I_______T
 ___________A_______S_______R
 _____________________________A

   Your success with girls will be much easier to achieve, when your staying power is supported by our branded solutions for men! Best prices this month only, and always nice service and full confidentiality! Try now, don�t disappoint hotties, demanding your stiff prick!
-
 - - -
--------- http://tusis.ru
 - - -
-