On Thu, Nov 13, 2008 at 05:49:50PM -0800, <email address hidden> wrote:
> --- Comment #1 from Peter Hutterer <email address hidden> 2008-11-13 17:49:49 PST ---
> On Thu, Nov 13, 2008 at 04:52:15PM -0800, <email address hidden>
> wrote:
> > Note: Special on my system is, that I have a Wacom Bamboo connected.
>
> my gut feeling is that that's the root cause here because I've seen similar
> issues here. Need to wait until my tablet arrives before I can debug that.
grep for 'long-standing misunderstanding': Wacom will always define a
keyboard feedback class, but not necessarily a key class. XkbHandleBell
expects a key class to exist as well as a keyboard feedback class, so if
we have a Wacom tablet with no keys, a bell will cause the server to
explode. I guess strengthening the test to (!dev->kbdfeed || !dev->key)
should solve this.
On Thu, Nov 13, 2008 at 05:49:50PM -0800, <email address hidden> wrote:
> --- Comment #1 from Peter Hutterer <email address hidden> 2008-11-13 17:49:49 PST ---
> On Thu, Nov 13, 2008 at 04:52:15PM -0800, <email address hidden>
> wrote:
> > Note: Special on my system is, that I have a Wacom Bamboo connected.
>
> my gut feeling is that that's the root cause here because I've seen similar
> issues here. Need to wait until my tablet arrives before I can debug that.
http:// linuxwacom. cvs.sourceforge .net/viewvc/ linuxwacom/ linuxwacom- dev/src/ xdrv/xf86Wacom. c?revision= 1.47&view= markup
grep for 'long-standing misunderstanding': Wacom will always define a
keyboard feedback class, but not necessarily a key class. XkbHandleBell
expects a key class to exist as well as a keyboard feedback class, so if
we have a Wacom tablet with no keys, a bell will cause the server to
explode. I guess strengthening the test to (!dev->kbdfeed || !dev->key)
should solve this.