Carson, FWIW, "we" are beating them...
I think that implementing a formal workaround should be straight forward. [I have not (yet) had the free cycles or machine access to experiment.] The build fails primarily because of missing "switch events" defined in <linux/input.h> /* * Switch events */ #define SW_LID 0x00 /* set = lid shut */ #define SW_TABLET_MODE 0x01 /* set = tablet mode */ #define SW_HEADPHONE_INSERT 0x02 /* set = inserted */ #define SW_MAX 0x0f To my thinking... If the existing kernel does not support the functionality associated with these switches, HAL should nod politely and roll on. A simple grep exposes the "culprits" [ignore line wrap] [EMAIL PROTECTED] hal-0.5.9]$ grep -r SW_ * | grep -v "*.o" hald/linux/device.c: long bitmask[NBITS(SW_MAX)]; hald/linux/device.c: if (test_bit (SW_LID, bitmask)) { hald/linux/device.c: } else if (test_bit (SW_TABLET_MODE, bitmask)) { hald/linux/device.c: } else if (test_bit (SW_HEADPHONE_INSERT, bitmask)) { hald/linux/probing/probe-input.c: long bitmask[NBITS(SW_MAX)]; hald/linux/probing/probe-input.c: sw = SW_LID; hald/linux/probing/probe-input.c: sw = SW_TABLET_MODE; hald/linux/probing/probe-input.c: sw = SW_HEADPHONE_INSERT; hald/linux/addons/addon-keyboard.c: case SW_LID: hald/linux/addons/addon-keyboard.c: case SW_TABLET_MODE: hald/linux/addons/addon-keyboard.c: case SW_HEADPHONE_INSERT: hald/linux/addons/addon-keyboard.c: long bitmask[NBITS(SW_MAX)]; Thoughts --------- * Can #ifndef blocks be used to locally specify the missing macros? * It should not be too difficult to short-circuit the errant code. * It would be better to have configure probe for the SW_ macros and set flags that could be used within #ifdef blocks. -Joseph ================================================================================== On Tue, 2007-06-19 at 15:01 -0700, Carson Gaspar wrote: > Joseph Sacco wrote: > > Dan, > > > > Can you fake it? If by "it" you mean the absence of kernel header files, > > the answer is "no". You will need to install the kernel header files > > for your distro. > > > > I don't believe that the 2.6.16.1 kernel is new enough to support the > > recent changes in HAL. > > > > What to do... > > > > There are choices: > > * update your kernel > > [I believe 2.6.17.1 will work] > > > > * retreat to the previous versions of hal and dbus. > > I vote for choice 3: > > * Beat the dbus/hal maintainers about the head and shoulders until they > understand that gratuitously breaking older kernels is a Very Bad Idea. > > *sigh* And people wonder why gnome has a bad rep... > > -- > Carson -- jsacco [at] gnome [dot] org -- garnome-list mailing list garnome-list@gnome.org http://mail.gnome.org/mailman/listinfo/garnome-list