Zen-Sources: 2.6.26-rc3-zen0

Message

vacula · Post by **vacula** » Mon May 26, 2008 6:19 pm

after upgrading from zen-sources 2.6.24 to linux-2.6.26-rc3-zen0 my keyboard/touchpad goes crazy:

#dmesg

psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: issuing reconnect request
Unable to query Synaptics hardware.
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly.
input: PS/2 Synaptics TouchPad as /class/input/input6
psmouse.c: TouchPad at isa0060/serio4/input0 lost synchronization, throwing 2 bytes away.
psmouse.c: failed to re-enable mouse on isa0060/serio4
psmouse.c: resync failed, issuing reconnect request
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly.
Synaptics Touchpad, model: 1, fw: 6.2, id: 0xa5a0b1, caps: 0xa04713/0x0
input: SynPS/2 Synaptics TouchPad as /class/input/input7
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: issuing reconnect request
atkbd.c: Spurious NAK on isa0060/serio0. Some program might be trying access hardware directly.
Synaptics Touchpad, model: 1, fw: 6.2, id: 0xa5a0b1, caps: 0xa04713/0x0
input: SynPS/2 Synaptics TouchPad as /class/input/input8
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: issuing reconnect request
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly.
Synaptics Touchpad, model: 1, fw: 6.2, id: 0xa5a0b1, caps: 0xa04713/0x0
input: SynPS/2 Synaptics TouchPad as /class/input/input9
Synaptics Touchpad, model: 1, fw: 6.2, id: 0xa5a0b1, caps: 0xa04713/0x0
input: SynPS/2 Synaptics TouchPad as /class/input/input10
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: issuing reconnect request
atkbd.c: Spurious NAK on isa0060/serio0. Some program might be trying access hardware directly.
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly.
Synaptics Touchpad, model: 1, fw: 6.2, id: 0xa5a0b1, caps: 0xa04713/0x0
input: SynPS/2 Synaptics TouchPad as /class/input/input11
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: issuing reconnect request
Synaptics Touchpad, model: 1, fw: 6.2, id: 0xa5a0b1, caps: 0xa04713/0x0
input: SynPS/2 Synaptics TouchPad as /class/input/input12
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
psmouse.c: issuing reconnect request
Unable to query Synaptics hardware.
input: PS/2 Synaptics TouchPad as /class/input/input13
psmouse.c: TouchPad at isa0060/serio4/input0 lost synchronization, throwing 1 bytes away.
psmouse.c: TouchPad at isa0060/serio4/input0 lost synchronization, throwing 2 bytes away.
psmouse.c: TouchPad at isa0060/serio4/input0 lost synchronization, throwing 2 bytes away.

Is it zen-sources regression or I should report somewhere else? If someone needs more configuration details of my system let me know plz.

kaosone · Post by **kaosone** » Mon May 26, 2008 11:26 pm

rmh3093 wrote:
well, i know that the touchscreen driver does the same type of crap, many touchscreens use the same chip but one on some screen the x axis will be inverted on others the y and on some both are inverted, i will have to dig my adapter out and see if its working or not, if your buttons were mapped to an axis, does that mean you axis were mapped to buttons, we might be able ot modify the patch to be configurable though menuconfig that way anyone could use the patch

ok you're not so wrong after all
i just cleaned up the code and added some configurations

Code: Select all

diff --git a/drivers/input/joydev.c b/drivers/input/joydev.c
index 65d7077..a5c6f99 100644
--- a/drivers/input/joydev.c
+++ b/drivers/input/joydev.c
@@ -25,15 +25,21 @@
 #include <linux/poll.h>
 #include <linux/init.h>
 #include <linux/device.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>

 MODULE_AUTHOR("Vojtech Pavlik <vojtech@ucw.cz>");
 MODULE_DESCRIPTION("Joystick device interfaces");
 MODULE_SUPPORTED_DEVICE("input/js");
 MODULE_LICENSE("GPL");
-
 #define JOYDEV_MINOR_BASE      0
 #define JOYDEV_MINORS          16
 #define JOYDEV_BUFFER_SIZE     64
+#define MAX_REMAP_SIZE         10
+
+static int remap_array[MAX_REMAP_SIZE];
+static int remap_count = 0;
+static int free_buttons[MAX_REMAP_SIZE];

 struct joydev {
        int exist;
@@ -72,6 +78,9 @@ struct joydev_client {
 static struct joydev *joydev_table[JOYDEV_MINORS];
 static DEFINE_MUTEX(joydev_table_mutex);

+module_param_array(remap_array, int, &remap_count, 0 );
+MODULE_PARM_DESC( remap_array, "remap axis to buttons\n" );
+
 static int joydev_correct(int value, struct js_corr *corr)
 {
        switch (corr->type) {
@@ -122,9 +131,19 @@ static void joydev_event(struct input_handle *handle,
        struct joydev *joydev = handle->private;
        struct joydev_client *client;
        struct js_event event;
+       int i;

+       if( remap_count > 0 && remap_count < MAX_REMAP_SIZE ){
+               for( i = 0; i < remap_count; i++ )
+                       if( code == remap_array[i] ){
+                               type = EV_KEY;
+                               code = free_buttons[i];
+                               if( value == 255 )
+                                       value = 1;
+                       }
+       }
+
        switch (type) {
-
        case EV_KEY:
                if (code < BTN_MISC || value == 2)
                        return;
@@ -725,7 +744,7 @@ static int joydev_connect(struct input_handler *handler, struct input_dev *dev,
                          const struct input_device_id *id)
 {
        struct joydev *joydev;
-       int i, j, t, minor;
+       int i, j = 0, t, minor;
        int error;

        for (minor = 0; minor < JOYDEV_MINORS; minor++)
@@ -768,15 +787,23 @@ static int joydev_connect(struct input_handler *handler, struct input_dev *dev,
                        joydev->keymap[i] = joydev->nkey;
                        joydev->keypam[joydev->nkey] = i + BTN_MISC;
                        joydev->nkey++;
+                       j = i;
+               }
+       if( remap_count > 0 && remap_count < MAX_REMAP_SIZE ){
+               printk( "[joydev] axis remapping enabled\n" );
+               for( i = 0; i < remap_count; i++ ){
+                       joydev->keymap[j + i + 1] = joydev->nkey;
+                       joydev->keypam[joydev->nkey] = i + j + 1 + BTN_MISC;
+                       free_buttons[i] = j + i + 1 + BTN_MISC;
+                       joydev->nkey++;
                }
-
        for (i = 0; i < BTN_JOYSTICK - BTN_MISC; i++)
                if (test_bit(i + BTN_MISC, dev->keybit)) {
                        joydev->keymap[i] = joydev->nkey;
                        joydev->keypam[joydev->nkey] = i + BTN_MISC;
                        joydev->nkey++;
                }
-
+       }
        for (i = 0; i < joydev->nabs; i++) {
                j = joydev->abspam[i];
                if (dev->absmax[j] == dev->absmin[j]) {

basically if you have for example event code 53 , 54 and 55 seen as axis but they are buttons instead, you just have to do this:

Code: Select all

modprobe joydev remap_array=53,54,55

3 buttons will be added and event codes will be remapped to those buttons

doing the inverse patch (button to axis) should be really similar
if you just have 2 axis or 2 buttons inverted you can use a patched version of jscal to remap those

edit: cleaned up code a little more

dodo1122 · Post by **dodo1122** » Tue May 27, 2008 3:13 pm

2.6.26-rc4-zen0 "Sayonara Zetsubō Sensei" tagged.

Ebuild will be available shortly.

EDIT:

Ebuild in zen-overlay

dodo

mroconnor · Post by **mroconnor** » Tue May 27, 2008 3:18 pm

dodo how is HDAPS support working for you? I am still having issues.

dodo1122 · Post by **dodo1122** » Tue May 27, 2008 3:22 pm

mroconnor wrote:dodo how is HDAPS support working for you? I am still having issues.

Yeah, it doesn't work here either. the hdaps module does not load:/ i fixed tp_smapi though, so it loads and works. i will have to look into hdaps, but it's strange that it doesn't work, because it should do.

dodo

mroconnor · Post by **mroconnor** » Tue May 27, 2008 3:29 pm

Yeah the smapi works like a charm....I am addicted to f'ing with my battery by forcing it to discharge, but the HDAPS I really like.

Do you use the tpb packages?

dodo1122 · Post by **dodo1122** » Tue May 27, 2008 3:37 pm

no, i never used tbp. I should try it

dodo

tranquilcool · Post by **tranquilcool** » Tue May 27, 2008 4:29 pm

kernel/sysctl.c

error: ‘hid_mousepoll_interval’ undeclared here (not in a function)
make[1]: *** [kernel/sysctl.o] Error 1
make: *** [kernel] Error 2

errors with latest pull v2.6.26-rc4-zen0.

dodo1122 · Post by **dodo1122** » Tue May 27, 2008 4:58 pm

tranquilcool wrote:kernel/sysctl.c error: ‘hid_mousepoll_interval’ undeclared here (not in a function)
make[1]: *** [kernel/sysctl.o] Error 1
make: *** [kernel] Error 2

errors with latest pull v2.6.26-rc4-zen0.

It compile here with allmodconfig, hence with

Code: Select all

CONFIG_USB_HID=m
CONFIG_USB_HID_MOUSE_POLLING=y
CONFIG_USB_HID_MOUSE_POLLING_INTERVAL=10
CONFIG_USB_HIDINPUT_POWERBOOK=y
CONFIG_USB_HIDDEV=y

can i see your cat .config | grep CONFIG_USB_HID ?

dodo

tranquilcool · Post by **tranquilcool** » Tue May 27, 2008 5:01 pm

dodo1122 wrote:
tranquilcool wrote:kernel/sysctl.c error: ‘hid_mousepoll_interval’ undeclared here (not in a function)
make[1]: *** [kernel/sysctl.o] Error 1
make: *** [kernel] Error 2

errors with latest pull v2.6.26-rc4-zen0.
It compile here with allmodconfig, hence with
Code: Select all
CONFIG_USB_HID=m
CONFIG_USB_HID_MOUSE_POLLING=y
CONFIG_USB_HID_MOUSE_POLLING_INTERVAL=10
CONFIG_USB_HIDINPUT_POWERBOOK=y
CONFIG_USB_HIDDEV=y
cat .config | grep CONFIG_USB_HID

CONFIG_USB_HID=y
# CONFIG_USB_HID_MOUSE_POLLING is not set
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
CONFIG_USB_HIDDEV=y

dodo

dodo1122 · Post by **dodo1122** » Tue May 27, 2008 5:13 pm

could you please change

Code: Select all

#ifdef CONFIG_USB_HID

in kernel/sysctl.c on line 1297 to

Code: Select all

#ifdef CONFIG_USB_HID_MOUSE_POLLING

and test? It compiles here when changed to #ifdef CONFIG_USB_HID_MOUSE_POLLING

Thanks,

dodo

tranquilcool · Post by **tranquilcool** » Tue May 27, 2008 5:23 pm

dodo1122 wrote:could you please change
Code: Select all
#ifdef CONFIG_USB_HID
in kernel/sysctl.c on line 1297 to
Code: Select all
#ifdef CONFIG_USB_HID_MOUSE_POLLING 
and test? It compiles here when changed to #ifdef CONFIG_USB_HID_MOUSE_POLLING

Thanks,

dodo

yes changing the line this way fixed it. 'am compiling now.

thanks.

dodo1122 · Post by **dodo1122** » Tue May 27, 2008 5:25 pm

No problem. just pushed the fix to master.

EDIT: proper fix commited for it now.

dodo

mroconnor · Post by **mroconnor** » Wed May 28, 2008 3:07 pm

Was there a problem with a merge last night or is my repo bollocks'd up?

dodo1122 · Post by **dodo1122** » Wed May 28, 2008 4:03 pm

as we told people in the past, with every new kernel release we rebase all branches, and make a new master ( merge all branches to it again). This means the branch is not related to the old one, and because of it people get loads and loads of conflicts. To fix this, do:

Code: Select all

git branch -M master master-old && git branch master origin/master && git checkout -f master && git branch -D master-old && git checkout -f

Also, rmh has put together a hotfix system for zen. This means that we have releases like before (-zen1,2,3 etc) and a hotfix, which is basically a fix for the major zen release ( compilation error, late feature, fixing up a driver etc). Hotfixes are basically new ebuilds, which have a -rYX, where X is the hotfix number, and Y is zen release. They are separate patches, so there is little to download.
There is a hotfix for the mouse polling, which did not work in -rc4-zen0 (which, by the way, was renamed to -zen1, as ebuilds do not like -r0X).

dodo

mroconnor · Post by **mroconnor** » Wed May 28, 2008 4:07 pm

thanks dodo. I wasn't paying attention to releases as usual.

rmh3093 · Post by **rmh3093** » Wed May 28, 2008 4:11 pm

dodo1122 wrote:as we told people in the past, with every new kernel release we rebase all branches, and make a new master ( merge all branches to it again). This means the branch is not related to the old one, and because of it people get loads and loads of conflicts. To fix this, do:
Code: Select all
git branch -M master master-old && git branch master origin/master && git checkout -f master && git branch -D master-old && git checkout -f
Also, rmh has put together a hotfix system for zen. This means that we have releases like before (-zen1,2,3 etc) and a hotfix, which is basically a fix for the major zen release ( compilation error, late feature, fixing up a driver etc). Hotfixes are basically new ebuilds, which have a -rYX, where X is the hotfix number, and Y is zen release. They are separate patches, so there is little to download.
There is a hotfix for the mouse polling, which did not work in -rc4-zen0 (which, by the way, was renamed to -zen1, as ebuilds do not like -r0X).

dodo

what he forgot to mention that zen kernels will now look like this 2.6.26-rc4-zen1.1, where the first number in the version tag -zen1.1 refers to the normal zen base, and the second number in the version tag -zen1.1 refers to the hotfix level, hotfix patches will also apply on top of past hotfixes, so when 2.6.26-rc4-zen1.2 comes out both hotfix1 and hotfix2 will be applied

termite · Post by **termite** » Wed May 28, 2008 8:15 pm

I'm not a big fan of the new hotfix system: every time someone puts in some tiny fix, emerge zen-sources emerges a whole new kernel tree, taking up tons of space. Since hotfixes are meant (by their very nature) to be small changes, this means we could get piles of different sources trees each day. I don't think there's a need for a new version for every hotfix. I like that it's easier to access the latest zen-sources from the overlay, but perhaps the new eclass isn't quite the right way.

Thanks for all your work guys, I really appreciate it!

unK · Post by **unK** » Wed May 28, 2008 8:43 pm

something's wrong with new ebuilds.

Code: Select all

localhost ~ # emerge zen-sources -pv

These are the packages that would be merged, in order:

Calculating dependencies |/usr/local/portage/layman/zen-overlay/sys-kernel/zen-sources/zen-sources-2.6.26_rc4-r12.ebuild: line 2: detect_version: command not found
 * 
 * ERROR: sys-kernel/zen-sources-2.6.26_rc4-r12 failed.
 * Call stack:
 *               ebuild.sh, line 1700:  Called die
 * The specific snippet of code:
 *   	source "${EBUILD}" || die "error sourcing ebuild"
 *  The die message:
 *   error sourcing ebuild
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * This ebuild is from an overlay: '/usr/local/portage/layman/zen-overlay/'
 * 
/usr/local/portage/layman/zen-overlay/sys-kernel/zen-sources/zen-sources-2.6.26_rc4-r11.ebuild: line 2: detect_version: command not found
 * 
 * ERROR: sys-kernel/zen-sources-2.6.26_rc4-r11 failed.
 * Call stack:
 *               ebuild.sh, line 1700:  Called die
 * The specific snippet of code:
 *   	source "${EBUILD}" || die "error sourcing ebuild"
 *  The die message:
 *   error sourcing ebuild
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * This ebuild is from an overlay: '/usr/local/portage/layman/zen-overlay/'
 * 
/usr/local/portage/layman/zen-overlay/sys-kernel/zen-sources/zen-sources-2.6.26_rc4-r10.ebuild: line 2: detect_version: command not found
 * 
 * ERROR: sys-kernel/zen-sources-2.6.26_rc4-r10 failed.
 * Call stack:
 *               ebuild.sh, line 1700:  Called die
 * The specific snippet of code:
 *   	source "${EBUILD}" || die "error sourcing ebuild"
 *  The die message:
 *   error sourcing ebuild
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * This ebuild is from an overlay: '/usr/local/portage/layman/zen-overlay/'
 *                                                                                ... done!
[ebuild   R   ] sys-kernel/zen-sources-2.6.26_rc3  USE="-symlink" 0 kB [1]

Total: 1 package (1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage/layman/zen-overlay

rmh3093 · Post by **rmh3093** » Wed May 28, 2008 8:52 pm

termite wrote:I'm not a big fan of the new hotfix system: every time someone puts in some tiny fix, emerge zen-sources emerges a whole new kernel tree, taking up tons of space. Since hotfixes are meant (by their very nature) to be small changes, this means we could get piles of different sources trees each day. I don't think there's a need for a new version for every hotfix. I like that it's easier to access the latest zen-sources from the overlay, but perhaps the new eclass isn't quite the right way.

Thanks for all your work guys, I really appreciate it!

u dont have to update if the hotfix isnt for you, there were 2 today just because we were testing shit out, the hotfix idea was so that you didnt have to download many large monolithic patches, which is what would happen if we just bumped the version number normally

...since you dont like this, what do you suggest?

rmh3093 · Post by **rmh3093** » Wed May 28, 2008 8:54 pm

unK wrote:something's wrong with new ebuilds.

Code: Select all

localhost ~ # emerge zen-sources -pv

These are the packages that would be merged, in order:

Calculating dependencies |/usr/local/portage/layman/zen-overlay/sys-kernel/zen-sources/zen-sources-2.6.26_rc4-r12.ebuild: line 2: detect_version: command not found
 * 
 * ERROR: sys-kernel/zen-sources-2.6.26_rc4-r12 failed.
 * Call stack:
 *               ebuild.sh, line 1700:  Called die
 * The specific snippet of code:
 *   	source "${EBUILD}" || die "error sourcing ebuild"
 *  The die message:
 *   error sourcing ebuild
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * This ebuild is from an overlay: '/usr/local/portage/layman/zen-overlay/'
 * 
/usr/local/portage/layman/zen-overlay/sys-kernel/zen-sources/zen-sources-2.6.26_rc4-r11.ebuild: line 2: detect_version: command not found
 * 
 * ERROR: sys-kernel/zen-sources-2.6.26_rc4-r11 failed.
 * Call stack:
 *               ebuild.sh, line 1700:  Called die
 * The specific snippet of code:
 *   	source "${EBUILD}" || die "error sourcing ebuild"
 *  The die message:
 *   error sourcing ebuild
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * This ebuild is from an overlay: '/usr/local/portage/layman/zen-overlay/'
 * 
/usr/local/portage/layman/zen-overlay/sys-kernel/zen-sources/zen-sources-2.6.26_rc4-r10.ebuild: line 2: detect_version: command not found
 * 
 * ERROR: sys-kernel/zen-sources-2.6.26_rc4-r10 failed.
 * Call stack:
 *               ebuild.sh, line 1700:  Called die
 * The specific snippet of code:
 *   	source "${EBUILD}" || die "error sourcing ebuild"
 *  The die message:
 *   error sourcing ebuild
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * This ebuild is from an overlay: '/usr/local/portage/layman/zen-overlay/'
 *                                                                                ... done!
[ebuild   R   ] sys-kernel/zen-sources-2.6.26_rc3  USE="-symlink" 0 kB [1]

Total: 1 package (1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage/layman/zen-overlay

something is wrong with your copy of the overlay, layman -d zen-overlay; layman -a zen-overlay

unK · Post by **unK** » Wed May 28, 2008 9:24 pm

rmh3093 wrote:something is wrong with your copy of the overlay, layman -d zen-overlay; layman -a zen-overlay

Did it, same result. However, I am using portage 2.2_pre.

termite · Post by **termite** » Wed May 28, 2008 9:29 pm

...since you dont like this, what do you suggest?

I think it's perfectly ok to let git users get every patch (as it just overwrites the old directory), and let layman users get a full new version (ie a new source tree) when you guys decide it's ready. I think this was more or less the old behavior. That way, if I re-emerge the same version, and you've added stuff to git, I get those changes without having a whole new source directory. One small patch doesn't require duplication of everything in the tree...

rmh3093 · Post by **rmh3093** » Wed May 28, 2008 9:39 pm

termite wrote:
...since you dont like this, what do you suggest?
I think it's perfectly ok to let git users get every patch (as it just overwrites the old directory), and let layman users get a full new version (ie a new source tree) when you guys decide it's ready. I think this was more or less the old behavior. That way, if I re-emerge the same version, and you've added stuff to git, I get those changes without having a whole new source directory. One small patch doesn't require duplication of everything in the tree...

the 9999 ebuild is just a stub which provides the kernel-sources virtual so that git uses dont keep getting prompted to install a kernel, it does not provide any source, you still need to clone manually

how about we unkeyword the hotfix ebuilds so that you have to manually add ** keyword, then they wont want to get installed automatically

dodo1122 · Post by **dodo1122** » Wed May 28, 2008 9:56 pm

Indeed, unkeywording the hotfix ebuilds is a good idea. And no, we cannot just leave major versions out there, as we can't test every configuration, hence we need feedback on how the kernel is performing, specific configuration compile errors, things not working etc. This is what hotfixes are for, to not bump the version with every bug fix.
And we will be working on a small script to pull hotfixes and apply them to the kernel, when they become available (kinda like the script nesl247 did for emission-sources and viper-sources).

dodo

Zen-Sources: 2.6.26-rc3-zen0

mouse/touchpad problem