tag:old.nabble.com,2006:forum-1065Nabble - Free Desktop - hal2009-12-04T21:08:11ZHardware Abstraction Layer technical discussion.tag:old.nabble.com,2006:post-26653159Re: hal 0.5.14 released2009-12-04T21:08:11Z2009-12-04T21:08:11ZJoe Marcus Clarke-2On Thu, 2009-12-03 at 20:28 -0600, Robby Workman wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On Thu, 03 Dec 2009 12:46:13 -0500
<br>> Joe Marcus Clarke <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653159&i=0" target="_top" rel="nofollow">marcus@...</a>> wrote:
<br>>
<br>> > On Tue, 2009-12-01 at 00:54 -0600, Robby Workman wrote:
<br>> > > On Tue, 01 Dec 2009 01:44:50 -0500
<br>> > > Joe Marcus Clarke <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653159&i=1" target="_top" rel="nofollow">marcus@...</a>> wrote:
<br>> > >
<br>> > > > This will tell me if it compiles, but not if it will work on
<br>> > > > FreeBSD. It should, though.
<br>> > >
<br>> > > After applying the patch (to 0.5.14 released sources) and running
<br>> > > autoreconf, I get this:
<br>> > >
<br>> > > configure: error: conditional "HAVE_LIBUSB20" was never defined.
<br>> > > Usually this means the macro was only invoked conditionally.
<br>> >
<br>> > Yeah, I got too greedy in my patch. Try this version.
<br>>
<br>>
<br>> Nope. Now this line is back during configure:
<br>>
<br>> checking for libusb20_dev_get_info in -lusb... no
<br>>
<br>> and this shows up after configure:
<br>>
<br>> use libusb: no
</div></div>I was able to start focusing on this, and this version works for
<br>FreeBSD. Does it do the trick on Linux as well?
<br><br>Joe
<br><br>>
<br>> -RW
<br><br><br>--
<br>PGP Key : <a href="http://www.marcuscom.com/pgp.asc" target="_top" rel="nofollow">http://www.marcuscom.com/pgp.asc</a><br><br /><tt>[usb.diff]</tt><br /><hr align="left" width="300" /><tt>diff --git a/configure.in b/configure.in
<br>index a8fda51..8363595 100644
<br>--- a/configure.in
<br>+++ b/configure.in
<br>@@ -479,9 +479,6 @@ if test "x$with_libpci" != xno ; then
<br> fi
<br> AM_CONDITIONAL([HAVE_LIBPCI], [test "x$USE_LIBPCI" = "xyes"])
<br>
<br>-USE_LIBUSB20=no
<br>-USE_LIBUSB=no
<br>-LIBUSB20_LIBS=""
<br> AC_ARG_WITH([backend],
<br> AS_HELP_STRING([--with-backend=<name>],
<br> [backend to use (linux/solaris/freebsd/dummy)]),
<br>@@ -510,21 +507,25 @@ AM_CONDITIONAL(HALD_COMPILE_FREEBSD, [test x$HALD_BACKEND = xfreebsd], [Compilin
<br> AM_CONDITIONAL(HALD_COMPILE_SOLARIS, [test x$HALD_BACKEND = xsolaris], [Compiling for Solaris])
<br> AC_SUBST(HALD_BACKEND)
<br> if test "x$HALD_BACKEND" = "xfreebsd"; then
<br>- AC_CHECK_LIB([usb20], [libusb20_dev_get_info], [USE_LIBUSB20=yes], [USE_LIBUSB20=no])
<br>-fi
<br>-if test "x$USE_LIBUSB20" = "xno"; then
<br>- AC_CHECK_LIB([usb], [libusb20_dev_get_info], [USE_LIBUSB=yes], [USE_LIBUSB=no])
<br>-fi
<br>-AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB20" = "xyes"])
<br>-AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB" = "xyes"])
<br>-if test "x$USE_LIBUSB20" = "xyes"; then
<br>- AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libusb20])
<br>- LIBUSB20_LIBS="-lusb20"
<br>-elif test "x$USE_LIBUSB" = "xyes"; then
<br>- AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libsub20])
<br>- LIBUSB20_LIBS="-lusb"
<br>+ USE_BSDLIBUSB20=no
<br>+ USE_BSDLIBUSB=no
<br>+ LIBUSB20_LIBS=""
<br>+ AC_CHECK_LIB([usb20], [libusb20_dev_get_info], [USE_BSDLIBUSB20=yes], [USE_BSDLIBUSB20=no])
<br>+ if test "x$USE_BSDLIBUSB20" = "xno"; then
<br>+ AC_CHECK_LIB([usb], [libusb20_dev_get_info], [USE_BSDLIBUSB=yes], [USE_BSDLIBUSB=no])
<br>+ fi
<br>+ AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_BSDLIBUSB20" = "xyes" -o "x$USE_BSDLIBUSB" = "xyes"])
<br>+ if test "x$USE_BSDLIBUSB20" = "xyes"; then
<br>+ AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libusb20])
<br>+ LIBUSB20_LIBS="-lusb20"
<br>+ elif test "x$USE_BSDLIBUSB" = "xyes"; then
<br>+ AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libsub20])
<br>+ LIBUSB20_LIBS="-lusb"
<br>+ fi
<br>+ AC_SUBST(LIBUSB20_LIBS)
<br>+else
<br>+ AM_CONDITIONAL([HAVE_LIBUSB20], [false])
<br> fi
<br>-AC_SUBST(LIBUSB20_LIBS)
<br>
<br> dnl DBUS API is subject to changes
<br> AC_DEFINE_UNQUOTED(DBUS_API_SUBJECT_TO_CHANGE, [], [DBUS API is subject to change])
<br></tt><hr align="left" width="300" /><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653159&i=2" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (203 bytes) <a href="http://old.nabble.com/attachment/26653159/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26647715Re: begging you : please do something for nv cards in hal2009-12-04T11:14:32Z2009-12-04T11:14:32ZMatthew GarrettOn Fri, Dec 04, 2009 at 08:09:01PM +0100, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647715&i=0" target="_top" rel="nofollow">schmirrwurst@...</a> wrote:
<br><br>> I'm not wanting hal to write in register itself, but only use smartdimmer to
<br>> control backlight for nvidia cards. Putting such a rule, is not a big long
<br>> term stability issue, and if I've understood, hal won't exist in long term
<br>> anymore...
<br><br>Having hal perform register writes and having hal call out to
<br>smartdimmer to perform register writes are equivalent. They're still the
<br>wrong thing to do.
<br><br>--
<br>Matthew Garrett | <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647715&i=1" target="_top" rel="nofollow">mjg59@...</a>
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647715&i=2" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26647480Re: begging you : please do something for nv cards in hal2009-12-04T10:58:42Z2009-12-04T10:58:42ZMatthew GarrettOn Fri, Dec 04, 2009 at 07:37:31PM +0100, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647480&i=0" target="_top" rel="nofollow">schmirrwurst@...</a> wrote:
<br>> Le vendredi 4 décembre 2009 19:23:40, vous avez écrit :
<br>> > kernel. It's not acceptable
<br>> > for hal to touch registers that may be used by other code.
<br>> >
<br>> I understand all those nice rules, but if kernel doesn't do anything, should
<br>> users do, wait until hw is obselete ? Nvidia has a market share from about
<br>> 35%...
<br><br>Users are (as is always the case with Linux) free to do whatever they
<br>want. However, hal is not a hardware driver. It's therefore not
<br>acceptable for hal to modify device registers directly. That's the
<br>kernel's responsibility.
<br><br>> -Hal say mus be done by kernel
<br><br>Right.
<br><br>> -kernel say it's a platform driver issue
<br><br>Occasionally. Sometimes it's a gpu driver issue, hence nouevau's support
<br>for backlight control.
<br><br>> I'm following this issue 2 years ago, and NOTHING has been done, now some
<br>> people have bought brand new hw, and they will probably wait a long time until
<br>> something happen, if things are going further like this
<br><br>Your only choice is to use nouveau or not to buy nvidia.
<br><br>> I though it was the aim of linux being usable on different hw platforms...
<br><br>It is, but the only way to achieve that is by implementing software
<br>properly rather than providing hacks that make things work in the short
<br>term but increase long-term instability and risk hardware damage.
<br><br>--
<br>Matthew Garrett | <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647480&i=1" target="_top" rel="nofollow">mjg59@...</a>
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647480&i=2" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26646903Re: begging you : please do something for nv cards in hal2009-12-04T10:23:40Z2009-12-04T10:23:40ZMatthew GarrettOn Fri, Dec 04, 2009 at 06:37:08PM +0100, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646903&i=0" target="_top" rel="nofollow">schmirrwurst@...</a> wrote:
<br><br>> The only solution I see, is that hal is managing backlight, for people using
<br>> nv or glx driver...
<br>> Changing backlight manually through smartdimmer or nvclock work, so I must no
<br>> be difficult to support it in hal ? Please !
<br><br>Hardware management has to be done in the kernel. It's not acceptable
<br>for hal to touch registers that may be used by other code.
<br><br>--
<br>Matthew Garrett | <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646903&i=1" target="_top" rel="nofollow">mjg59@...</a>
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646903&i=2" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26646678Re: begging you : please do something for nv cards in hal2009-12-04T10:08:59Z2009-12-04T10:08:59ZschmirrwurstBut Martin, users like me (and it seems also the case from user with brand new
<br>laptop with nv cards), can't wait another 2 years having a stable nouveau
<br>driver !! or another solution...
<br><br>The current smartdimmer in karmic is working to get and set backlight on my
<br>laptop... It must be possible to make use of this in hal ?
<br><br><br>I think, even if hal is no more default, it is easyer to have to install a
<br>package, for an ubuntu newbie, thant having to use command line with
<br>smartdimmer, or write a script... Having hal supporting it, could be a
<br>solution until nouveau is more stable... (on my hw, kms is crashing the
<br>system, and with or without, I'm unable to play videos....)
<br><br>That's why I'm using the nv driver, (not glx), that is free I think.
<br><br>Le vendredi 4 décembre 2009 18:58:50, Martin Pitt a écrit :
<div class='shrinkable-quote'><br>> Hello,
<br>>
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646678&i=0" target="_top" rel="nofollow">schmirrwurst@...</a> [2009-12-04 18:37 +0100]:
<br>> > -Nvidia will never support backlight in his driver (dixit nvidia
<br>> > support)
<br>>
<br>> Their problem really ... I'm afraid that's (a) price you have to pay
<br>> for using the proprietary driver. By their very nature you depend on
<br>> the manufacturer to do things right.
<br>>
<br>> > -Kernel isn't doing anything, problem as been reported, but nothing
<br>> > happens
<br>>
<br>> And they can't, there is no way the linux kernel could do anything
<br>> about making the proprietary driver work.
<br>>
<br>> > -Nouveau driver from freedesktop is managing backlight, but is too
<br>> > unstable to use in production.
<br>>
<br>> Nevertheless this probably seems like the way forward, especially it
<br>> also gets KMS support now. It's said to have at least rudimentary
<br>> xbacklight support.
<br>>
<br>> > The only solution I see, is that hal is managing backlight, for people
<br>> > using nv or glx driver...
<br>> > Changing backlight manually through smartdimmer or nvclock work, so I
<br>> > must no be difficult to support it in hal ? Please !
<br>>
<br>> Ubuntu has carried a patch for smartdimmer support, but it wasn't
<br>> accepted upstream [1]. However, hal very likely won't be in the default
<br>> installation any more from next week on (in the development release),
<br>> but we might pull it back in as a dependency of the proprietary driver
<br>> package for this.
<br>>
<br>> With hal development (and usage) being ceased now, I don't think that
<br>> it makes a lot of sense to pursue this further in hal, though.
<br>>
<br>> Martin
<br>>
<br>> [1] <a href="http://lists.freedesktop.org/pipermail/hal/2009-January/012858.html" target="_top" rel="nofollow">http://lists.freedesktop.org/pipermail/hal/2009-January/012858.html</a><br>>
</div>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646678&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26646500Re: begging you : please do something for nv cards in hal2009-12-04T09:58:50Z2009-12-04T09:58:50ZMartin Pitt-4Hello,
<br><br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646500&i=0" target="_top" rel="nofollow">schmirrwurst@...</a> [2009-12-04 18:37 +0100]:
<br>> -Nvidia will never support backlight in his driver (dixit nvidia support)
<br><br>Their problem really ... I'm afraid that's (a) price you have to pay
<br>for using the proprietary driver. By their very nature you depend on
<br>the manufacturer to do things right.
<br><br>> -Kernel isn't doing anything, problem as been reported, but nothing happens
<br><br>And they can't, there is no way the linux kernel could do anything
<br>about making the proprietary driver work.
<br><br>> -Nouveau driver from freedesktop is managing backlight, but is too unstable
<br>> to use in production.
<br><br>Nevertheless this probably seems like the way forward, especially it
<br>also gets KMS support now. It's said to have at least rudimentary
<br>xbacklight support.
<br><br>> The only solution I see, is that hal is managing backlight, for people using
<br>> nv or glx driver...
<br>> Changing backlight manually through smartdimmer or nvclock work, so I must no
<br>> be difficult to support it in hal ? Please !
<br><br>Ubuntu has carried a patch for smartdimmer support, but it wasn't
<br>accepted upstream [1]. However, hal very likely won't be in the default
<br>installation any more from next week on (in the development release),
<br>but we might pull it back in as a dependency of the proprietary driver
<br>package for this.
<br><br>With hal development (and usage) being ceased now, I don't think that
<br>it makes a lot of sense to pursue this further in hal, though.
<br><br>Martin
<br><br>[1] <a href="http://lists.freedesktop.org/pipermail/hal/2009-January/012858.html" target="_top" rel="nofollow">http://lists.freedesktop.org/pipermail/hal/2009-January/012858.html</a><br><br>--
<br>Martin Pitt | <a href="http://www.piware.de" target="_top" rel="nofollow">http://www.piware.de</a><br>Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646500&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26646178begging you : please do something for nv cards in hal2009-12-04T09:37:08Z2009-12-04T09:37:08ZschmirrwurstI'm experiencing (like a lot of other users) problems with backlight support
<br>with my nv50 (geforce 8) nvidia card. and that about 2 years ago !
<br> -Nvidia will never support backlight in his driver (dixit nvidia support)
<br> -Kernel isn't doing anything, problem as been reported, but nothing happens
<br> -Nouveau driver from freedesktop is managing backlight, but is too unstable
<br>to use in production.
<br><br>The only solution I see, is that hal is managing backlight, for people using
<br>nv or glx driver...
<br> Changing backlight manually through smartdimmer or nvclock work, so I must no
<br>be difficult to support it in hal ? Please !
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646178&i=0" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26639901Re: hal 0.5.14 released2009-12-04T01:32:42Z2009-12-04T01:32:42ZMichael Biebl-22009/12/3 Joe Marcus Clarke <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26639901&i=0" target="_top" rel="nofollow">marcus@...</a>>:
<div class='shrinkable-quote'><br>> On Tue, 2009-12-01 at 00:54 -0600, Robby Workman wrote:
<br>>> On Tue, 01 Dec 2009 01:44:50 -0500
<br>>> Joe Marcus Clarke <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26639901&i=1" target="_top" rel="nofollow">marcus@...</a>> wrote:
<br>>>
<br>>> > This will tell me if it compiles, but not if it will work on FreeBSD.
<br>>> > It should, though.
<br>>>
<br>>> After applying the patch (to 0.5.14 released sources) and running
<br>>> autoreconf, I get this:
<br>>>
<br>>> configure: error: conditional "HAVE_LIBUSB20" was never defined.
<br>>> Usually this means the macro was only invoked conditionally.
<br>>
<br>> Yeah, I got too greedy in my patch. Try this version.
</div><br>The logic is pretty weird.
<br>First you set USE_LIBUSB20=no and USE_LIBUSB=no
<br>if you then find LIBUSB20, you won't check for LIBUSB so
<br><br>AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB20" = "xyes"])
<br>AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB" = "xyes"])
<br><br>will first set HAVE_LIBUSB20 to yes and then to no.
<br><br>I guess you need to rework this again.
<br><br>Cheers,
<br>Michael
<br><br>--
<br>Why is it that all of the instruments seeking intelligent life in the
<br>universe are pointed away from Earth?
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26639901&i=2" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26637012Re: hal 0.5.14 released2009-12-03T18:28:54Z2009-12-03T18:28:54ZRobby Workman-6On Thu, 03 Dec 2009 12:46:13 -0500
<br>Joe Marcus Clarke <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26637012&i=0" target="_top" rel="nofollow">marcus@...</a>> wrote:
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On Tue, 2009-12-01 at 00:54 -0600, Robby Workman wrote:
<br>> > On Tue, 01 Dec 2009 01:44:50 -0500
<br>> > Joe Marcus Clarke <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26637012&i=1" target="_top" rel="nofollow">marcus@...</a>> wrote:
<br>> >
<br>> > > This will tell me if it compiles, but not if it will work on
<br>> > > FreeBSD. It should, though.
<br>> >
<br>> > After applying the patch (to 0.5.14 released sources) and running
<br>> > autoreconf, I get this:
<br>> >
<br>> > configure: error: conditional "HAVE_LIBUSB20" was never defined.
<br>> > Usually this means the macro was only invoked conditionally.
<br>>
<br>> Yeah, I got too greedy in my patch. Try this version.
</div></div><br>Nope. Now this line is back during configure:
<br><br> checking for libusb20_dev_get_info in -lusb... no
<br><br>and this shows up after configure:
<br><br> use libusb: no
<br><br>-RW
<br><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26637012&i=2" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (205 bytes) <a href="http://old.nabble.com/attachment/26637012/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26630563Re: 0.5.14 compiles with libusb: no2009-12-03T10:15:39Z2009-12-03T10:15:39ZJoe Marcus Clarke-2On Thu, 2009-12-03 at 18:58 +0100, Bela Markus wrote:
<br>> Thanks for the response. However it is not cosmetic only. Testing with
<br>> 'lshal -m' plugged USB sticks are not recognized by 0.5.14 while 0.5.13
<br>> lists them as expected.
<br><br>Actually, there is a non-cosmetic piece. The usb-csr piece won't work.
<br>I don't use Linux, but I highly doubt this would interfere with umass
<br>devices being recognized. Send the full output of running configure.
<br><br>Joe
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>>
<br>> Regards... Béla
<br>>
<br>> Joe Marcus Clarke írta:
<br>> > On Thu, 2009-12-03 at 18:30 +0100, Bela Markus wrote:
<br>> >
<br>> >> Compiling 0.5.04 configure sunnary says:
<br>> >>
<br>> >> use libusb: no
<br>> >>
<br>> >> In the same environment with same options 0.5.13 compiles with libusb
<br>> >> just fine. I have libusb 1.0.6 (latest) installed; minimum is 0.1.10a
<br>> >> according to the NEWS file.
<br>> >>
<br>> >> Any idea, what is missing?
<br>> >>
<br>> >
<br>> > This is a cosmetic issue on Linux which was caused by my changes for the
<br>> > new FreeBSD USB stack. It should not cause any functional problem. I
<br>> > hope to have a fix in git by this weekend.
<br>> >
<br>> > Joe
<br>> >
<br>> >
<br>> > ------------------------------------------------------------------------
<br>> >
<br>> > _______________________________________________
<br>> > hal mailing list
<br>> > <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26630563&i=0" target="_top" rel="nofollow">hal@...</a>
<br>> > <a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>> >
<br>>
<br>> _______________________________________________
<br>> hal mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26630563&i=1" target="_top" rel="nofollow">hal@...</a>
<br>> <a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>>
</div></div><br>--
<br>PGP Key : <a href="http://www.marcuscom.com/pgp.asc" target="_top" rel="nofollow">http://www.marcuscom.com/pgp.asc</a><br><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26630563&i=2" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (203 bytes) <a href="http://old.nabble.com/attachment/26630563/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26630391Re: 0.5.14 compiles with libusb: no2009-12-03T09:58:17Z2009-12-03T09:58:17ZBela Markus-3Thanks for the response. However it is not cosmetic only. Testing with
<br>'lshal -m' plugged USB sticks are not recognized by 0.5.14 while 0.5.13
<br>lists them as expected.
<br><br>Regards... Béla
<br><br>Joe Marcus Clarke írta:
<div class='shrinkable-quote'><br>> On Thu, 2009-12-03 at 18:30 +0100, Bela Markus wrote:
<br>>
<br>>> Compiling 0.5.04 configure sunnary says:
<br>>>
<br>>> use libusb: no
<br>>>
<br>>> In the same environment with same options 0.5.13 compiles with libusb
<br>>> just fine. I have libusb 1.0.6 (latest) installed; minimum is 0.1.10a
<br>>> according to the NEWS file.
<br>>>
<br>>> Any idea, what is missing?
<br>>>
<br>>
<br>> This is a cosmetic issue on Linux which was caused by my changes for the
<br>> new FreeBSD USB stack. It should not cause any functional problem. I
<br>> hope to have a fix in git by this weekend.
<br>>
<br>> Joe
<br>>
<br>>
<br>> ------------------------------------------------------------------------
<br>>
<br>> _______________________________________________
<br>> hal mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26630391&i=0" target="_top" rel="nofollow">hal@...</a>
<br>> <a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>>
</div><br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26630391&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26630125Re: 0.5.14 compiles with libusb: no2009-12-03T09:47:11Z2009-12-03T09:47:11ZJoe Marcus Clarke-2On Thu, 2009-12-03 at 18:30 +0100, Bela Markus wrote:
<br>> Compiling 0.5.04 configure sunnary says:
<br>>
<br>> use libusb: no
<br>>
<br>> In the same environment with same options 0.5.13 compiles with libusb
<br>> just fine. I have libusb 1.0.6 (latest) installed; minimum is 0.1.10a
<br>> according to the NEWS file.
<br>>
<br>> Any idea, what is missing?
<br><br>This is a cosmetic issue on Linux which was caused by my changes for the
<br>new FreeBSD USB stack. It should not cause any functional problem. I
<br>hope to have a fix in git by this weekend.
<br><br>Joe
<br><br>--
<br>PGP Key : <a href="http://www.marcuscom.com/pgp.asc" target="_top" rel="nofollow">http://www.marcuscom.com/pgp.asc</a><br><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26630125&i=0" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (203 bytes) <a href="http://old.nabble.com/attachment/26630125/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26630110Re: hal 0.5.14 released2009-12-03T09:46:13Z2009-12-03T09:46:13ZJoe Marcus Clarke-2On Tue, 2009-12-01 at 00:54 -0600, Robby Workman wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On Tue, 01 Dec 2009 01:44:50 -0500
<br>> Joe Marcus Clarke <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26630110&i=0" target="_top" rel="nofollow">marcus@...</a>> wrote:
<br>>
<br>> > This will tell me if it compiles, but not if it will work on FreeBSD.
<br>> > It should, though.
<br>>
<br>> After applying the patch (to 0.5.14 released sources) and running
<br>> autoreconf, I get this:
<br>>
<br>> configure: error: conditional "HAVE_LIBUSB20" was never defined.
<br>> Usually this means the macro was only invoked conditionally.
</div></div>Yeah, I got too greedy in my patch. Try this version.
<br><br>Joe
<br><br>>
<br>> -RW
<br><br><br>--
<br>PGP Key : <a href="http://www.marcuscom.com/pgp.asc" target="_top" rel="nofollow">http://www.marcuscom.com/pgp.asc</a><br><br /><tt>[usb.diff]</tt><br /><hr align="left" width="300" /><tt>diff --git a/configure.in b/configure.in
<br>index a8fda51..7c9e1eb 100644
<br>--- a/configure.in
<br>+++ b/configure.in
<br>@@ -479,9 +479,6 @@ if test "x$with_libpci" != xno ; then
<br> fi
<br> AM_CONDITIONAL([HAVE_LIBPCI], [test "x$USE_LIBPCI" = "xyes"])
<br>
<br>-USE_LIBUSB20=no
<br>-USE_LIBUSB=no
<br>-LIBUSB20_LIBS=""
<br> AC_ARG_WITH([backend],
<br> AS_HELP_STRING([--with-backend=<name>],
<br> [backend to use (linux/solaris/freebsd/dummy)]),
<br>@@ -510,21 +507,26 @@ AM_CONDITIONAL(HALD_COMPILE_FREEBSD, [test x$HALD_BACKEND = xfreebsd], [Compilin
<br> AM_CONDITIONAL(HALD_COMPILE_SOLARIS, [test x$HALD_BACKEND = xsolaris], [Compiling for Solaris])
<br> AC_SUBST(HALD_BACKEND)
<br> if test "x$HALD_BACKEND" = "xfreebsd"; then
<br>+ USE_LIBUSB20=no
<br>+ USE_LIBUSB=no
<br>+ LIBUSB20_LIBS=""
<br> AC_CHECK_LIB([usb20], [libusb20_dev_get_info], [USE_LIBUSB20=yes], [USE_LIBUSB20=no])
<br>+ if test "x$USE_LIBUSB20" = "xno"; then
<br>+ AC_CHECK_LIB([usb], [libusb20_dev_get_info], [USE_LIBUSB=yes], [USE_LIBUSB=no])
<br>+ fi
<br>+ AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB20" = "xyes"])
<br>+ AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB" = "xyes"])
<br>+ if test "x$USE_LIBUSB20" = "xyes"; then
<br>+ AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libusb20])
<br>+ LIBUSB20_LIBS="-lusb20"
<br>+ elif test "x$USE_LIBUSB" = "xyes"; then
<br>+ AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libsub20])
<br>+ LIBUSB20_LIBS="-lusb"
<br>+ fi
<br>+ AC_SUBST(LIBUSB20_LIBS)
<br>+else
<br>+ AM_CONDITIONAL([HAVE_LIBUSB20], [false])
<br> fi
<br>-if test "x$USE_LIBUSB20" = "xno"; then
<br>- AC_CHECK_LIB([usb], [libusb20_dev_get_info], [USE_LIBUSB=yes], [USE_LIBUSB=no])
<br>-fi
<br>-AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB20" = "xyes"])
<br>-AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB" = "xyes"])
<br>-if test "x$USE_LIBUSB20" = "xyes"; then
<br>- AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libusb20])
<br>- LIBUSB20_LIBS="-lusb20"
<br>-elif test "x$USE_LIBUSB" = "xyes"; then
<br>- AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libsub20])
<br>- LIBUSB20_LIBS="-lusb"
<br>-fi
<br>-AC_SUBST(LIBUSB20_LIBS)
<br>
<br> dnl DBUS API is subject to changes
<br> AC_DEFINE_UNQUOTED(DBUS_API_SUBJECT_TO_CHANGE, [], [DBUS API is subject to change])
<br></tt><hr align="left" width="300" /><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26630110&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (203 bytes) <a href="http://old.nabble.com/attachment/26630110/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-266299670.5.14 compiles with libusb: no2009-12-03T09:30:26Z2009-12-03T09:30:26ZBela Markus-3Compiling 0.5.04 configure sunnary says:
<br><br>use libusb: no
<br><br>In the same environment with same options 0.5.13 compiles with libusb
<br>just fine. I have libusb 1.0.6 (latest) installed; minimum is 0.1.10a
<br>according to the NEWS file.
<br><br>Any idea, what is missing?
<br><br>Thanks... Béla
<br><br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26629967&i=0" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26627372Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE2009-12-03T07:01:35Z2009-12-03T07:01:35ZMatthew GarrettOn Thu, Dec 03, 2009 at 10:22:16AM +0100, Corentin Chary wrote:
<br><br>> Dear system infrastructure people,
<br>> Do you think a KEY_WIRELESS_CYCLE key would have any application ?
<br><br>Not really. I've got a KEY_RFKILL patch queued, with the intended
<br>semantics being for rfkill-input to just toggle all devices. If a
<br>userspace rfkill daemon is running, it could use that to implement the
<br>cycle policy you want. I don't think we need both.
<br><br>--
<br>Matthew Garrett | <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26627372&i=0" target="_top" rel="nofollow">mjg59@...</a>
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26627372&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26623162Re: [PATCH 32/33] input: add KEY_WIRELESS_CYCLE2009-12-03T01:22:16Z2009-12-03T01:22:16ZCorentin Chary-2On Thu, Dec 3, 2009 at 9:57 AM, Dmitry Torokhov
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26623162&i=0" target="_top" rel="nofollow">dmitry.torokhov@...</a>> wrote:
<div class='shrinkable-quote'><br>> On Thu, Dec 03, 2009 at 09:51:59AM +0100, Corentin Chary wrote:
<br>>> On Thu, Dec 3, 2009 at 9:21 AM, Dmitry Torokhov
<br>>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26623162&i=1" target="_top" rel="nofollow">dmitry.torokhov@...</a>> wrote:
<br>>> > On Thu, Dec 03, 2009 at 09:12:52AM +0100, Corentin Chary wrote:
<br>>> >> On Thu, Dec 3, 2009 at 8:54 AM, Dmitry Torokhov
<br>>> >> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26623162&i=2" target="_top" rel="nofollow">dmitry.torokhov@...</a>> wrote:
<br>>> >> > On Thu, Dec 03, 2009 at 08:45:16AM +0100, Corentin Chary wrote:
<br>>> >> >> This keycode could be used in a lot of platform specific drivers.
<br>>> >> >> For example, on Asus laptops, Fn+F2 allow to cycle trought wireless
<br>>> >> >> drivers (bt/wl: off/off, on/off, off/on, on/on).
<br>>> >> >>
<br>>> >> >> Currently, these key are mapped to KEY_WLAN, and KEY_BLUETOOTH/KEY_WIMAX
<br>>> >> >> are rarely used.
<br>>> >> >>
<br>>> >> >
<br>>> >> > Is there any application support for such cycling? IOW does anyone cares
<br>>> >> > to do such cycling?
<br>>> >>
<br>>> >> On Asus laptops (both asus and eeepc) the Fn+F2 key cycle
<br>>> >> (bluetooth/wlan: on/on, on/off, off/on, off/off) on windows.
<br>>> >> On Linux, it only produces a KEY_WLAN keycode.
<br>>> >>
<br>>> >
<br>>> > I understand this. I guess the question is whether people working on
<br>>> > system infrastructure (dbus, Networkmanager, etc) care about having such
<br>>> > functionality on Linux? The reason I am asking is that we added all
<br>>> > KEY_WIMAX and so on defines but I am not usre if anyone wants them.
<br>>>
<br>>> KEY_WIMAX may not be used a lot because there is not a lot of device
<br>>> with such a key,
<br>>> I think this is not the case for KEY_WIRELESS_CYCLE.
<br>>>
<br>>> The bad thing is that we will need to patch X11 (and Qt, for
<br>>> kde/solid) to make it works.
<br>>>
<br>>> Maybe we should Cc dbus/network manager/solid/linux-wireless ?
<br>>>
<br>>
<br>> That would be a good idea.
</div><br>Here it is.
<br><br>Dear system infrastructure people,
<br>Do you think a KEY_WIRELESS_CYCLE key would have any application ?
<br><br>--
<br>Corentin Chary
<br><a href="http://xf.iksaif.net" target="_top" rel="nofollow">http://xf.iksaif.net</a><br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26623162&i=3" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26618552Re: Patch to allow for privacy-protected /proc2009-12-02T15:31:56Z2009-12-02T15:31:56ZMartin Pitt-4Johannes Bauer [2009-12-02 19:43 +0100]:
<br>> Your code also suggest that this problem was anticipated: support for
<br>> initgroups(2) was not completely removed, but made conditional (with the
<br>> variable controlling its call hardcoded to 0).
<br><br>It actually had a wildly different background. In its early childhood,
<br>hald ran as unprivileged system user with some extra groups which
<br>allowed it device access (such as a "plugdev" group to mount USB
<br>sticks), at least on some distros. Those were the days... :-)
<br><br>It was never meant to be used for privacy reasons, and it would feel a
<br>bit overkill and a step backwards to me to introduce a new system
<br>group for /proc, when we have worked hard to eliminate the need for
<br>most of these groups now.
<br><br>Martin
<br>--
<br>Martin Pitt | <a href="http://www.piware.de" target="_top" rel="nofollow">http://www.piware.de</a><br>Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26618552&i=0" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26614146Re: Patch to allow for privacy-protected /proc2009-12-02T10:43:34Z2009-12-02T10:43:34Zfoobar31415Gordon Messmer schrieb:
<br>> On 12/02/2009 05:49 AM, Johannes Bauer wrote:
<br>>> Wow, this is some objective opinion. Do you have something non-insulting
<br>>> to contribute or are you done?
<br>>
<br>> Openwall used to provide a patch for Linux that added some privacy to
<br>> /proc, without completely breaking user access to ps tools. If you're
<br>> interested in resurrecting it, you might be better off chasing that option.
<br><br>Hmm, the charme of a 750 /proc is that it basically works out-of-the-box
<br>with any vanilla Linux. And this setup does its job nicely in a couple
<br>of servers we set up - unfortunately it breaks hald.
<br><br>Your code also suggest that this problem was anticipated: support for
<br>initgroups(2) was not completely removed, but made conditional (with the
<br>variable controlling its call hardcoded to 0).
<br><br>Regards,
<br>Johannes
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26614146&i=0" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26612191Re: Patch to allow for privacy-protected /proc2009-12-02T08:47:23Z2009-12-02T08:47:23ZGordon MessmerOn 12/02/2009 05:49 AM, Johannes Bauer wrote:
<br>> Wow, this is some objective opinion. Do you have something non-insulting
<br>> to contribute or are you done?
<br>>
<br><br>Openwall used to provide a patch for Linux that added some privacy to
<br>/proc, without completely breaking user access to ps tools. If you're
<br>interested in resurrecting it, you might be better off chasing that option.
<br><br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26612191&i=0" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26609161Re: Patch to allow for privacy-protected /proc2009-12-02T05:49:39Z2009-12-02T05:49:39Zfoobar31415Lennart Poettering schrieb:
<br>> On Wed, 02.12.09 13:42, Johannes Bauer (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26609161&i=0" target="_top" rel="nofollow">dfnsonfsduifb@...</a>) wrote:
<br>>
<br>>> Having /proc with 755 is a privacy problem.
<br>>
<br>> The only problem I see here is that some folks apparently have too
<br>> much time to smoke crack.
<br><br>Wow, this is some objective opinion. Do you have something non-insulting
<br>to contribute or are you done?
<br><br>Regards,
<br>Johannes
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26609161&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26608574Re: Patch to allow for privacy-protected /proc2009-12-02T05:06:45Z2009-12-02T05:06:45ZLennart Poettering-10On Wed, 02.12.09 13:42, Johannes Bauer (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608574&i=0" target="_top" rel="nofollow">dfnsonfsduifb@...</a>) wrote:
<br><br>> Having /proc with 755 is a privacy problem.
<br><br>The only problem I see here is that some folks apparently have too
<br>much time to smoke crack.
<br><br>Say no to drugs! (Some of them at least)
<br><br>Lennart
<br><br>--
<br>Lennart Poettering Red Hat, Inc.
<br>lennart [at] poettering [dot] net
<br><a href="http://0pointer.net/lennart/" target="_top" rel="nofollow">http://0pointer.net/lennart/</a> GnuPG 0x1A015CC4
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608574&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26608277Patch to allow for privacy-protected /proc2009-12-02T04:42:47Z2009-12-02T04:42:47Zfoobar31415Dear list,
<br><br>I've proposed a patch to the Gentoo developers, as HAL is in
<br>maintenance mode ("no new features are added"). However, I was
<br>redirected to you ("You actually want to submit such patch upstream"),
<br>which is why I will repost my original message here. The original
<br>posting be found at <a href="https://bugs.gentoo.org/show_bug.cgi?id=294939" target="_top" rel="nofollow">https://bugs.gentoo.org/show_bug.cgi?id=294939</a> .
<br>I've not attached the (trivial) patch here, but it is available at
<br><a href="https://bugs.gentoo.org/attachment.cgi?id=211392" target="_top" rel="nofollow">https://bugs.gentoo.org/attachment.cgi?id=211392</a> .
<br><br>Kind regards,
<br>Johannes
<br><br><br><br><br>Original message follows:
<br><br>Having /proc with 755 is a privacy problem: Another user can, for
<br>example, see by using "ps" what movies others are watching, etc. A
<br>solution for this is making /proc 750 and chown it to root:procers. Only
<br>users who are added to procers may monitor proc support.
<br><br>In order to get hald running that way, the "haldaemon" user obviously
<br>has to be added to the procers group. When everything is set up this
<br>way, hald still will refuse to work and crash immediately on startup.
<br>This is because the hald developers are not calling initgroups(2).
<br>Obviously, auxiliary groups are not needed to be initialized when /proc
<br>has 755 permissions.
<br><br>However, in a setup like the above described, it is necessary for hald
<br>to perform the initgroups(2) call. Luckily, the change to the code is
<br>minimal as such a thing was already thought of (the appropriate function
<br>receives a parameter, which is in the current code always set to "0"
<br>however).
<br><br>The patch I propose (because HAL is out of maintenance and they won't
<br>accept patches) will enable the user to supply a command line parameter
<br>which will optionally enable auxiliary group support
<br>("--keep-auxgroups"). If it is not specified, everything will run normally.
<br><br>Reproducible: Always
<br><br>Steps to Reproduce:
<br>1. chmod 750 /proc
<br>2. chown root:procers /proc
<br>3. Add "haldaemon" to "procers" groups
<br>4. Start hald
<br>Actual Results:
<br>09:59:12.577 [I] hald.c:671: hal 0.5.12rc1
<br>09:59:12.577 [I] hald.c:736: Will not daemonize
<br>09:59:12.577 [I] hald_dbus.c:5417: local server is listening at
<br>unix:abstract=/var/run/hald/dbus-zf0EZzH5vG,guid=298760b1518ad88b9c6405a84b10e660
<br>09:59:12.578 [I] ck-tracker.c:391: got seat
<br>'/org/freedesktop/ConsoleKit/Seat1'
<br>09:59:12.579 [I] ck-tracker.c:321: got session
<br>'/org/freedesktop/ConsoleKit/Session2' for seat
<br>'/org/freedesktop/ConsoleKit/Seat1'
<br>09:59:12.579 [I] ck-tracker.c:274: Got active state (ACTIVE) and uid 1000 on
<br>session '/org/freedesktop/ConsoleKit/Session2'
<br>09:59:12.579 [I] ck-tracker.c:342: Got all sessions on seat
<br>'/org/freedesktop/ConsoleKit/Seat1'
<br>09:59:12.579 [I] ck-tracker.c:418: Got seats
<br>09:59:12.579 [I] ck-tracker.c:816: Got seats and sessions
<br>Runner started - allowed paths are
<br>'/usr/libexec:/usr/lib64/hal/scripts:/usr/bin'
<br>09:59:12.581 [I] hald_runner.c:301: Runner has pid 4358
<br>09:59:12.581 [I] hald_runner.c:182: runner connection is 0x664320
<br>09:59:12.581 [W] osspec.c:383: Unable to open /proc/mdstat: No such file or
<br>directory
<br>09:59:12.582 [I] mmap_cache.c:274: cache mtime is 1257707879
<br>*** [DIE] osspec.c:osspec_init():439 : Unable to read /proc/mounts
<br><br><br>Expected Results:
<br>Hald starts nicely.
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608277&i=0" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26608209Re: [Pm-utils] Experimental quirk handling in pm-utils2009-12-02T04:33:54Z2009-12-02T04:33:54ZRichard Hughes-62009/12/1 Victor Lowther <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608209&i=0" target="_top" rel="nofollow">victor.lowther@...</a>>:
<br>> It works for me, but none of the system I own end up actually querying
<br>> the quirk database. :)
<br><br>If it helps, I'm in a 100% KMS world right now too.
<br><br>Richard.
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608209&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26587887Re: Migrating suspend quirks away from hal2009-11-30T23:56:24Z2009-11-30T23:56:24ZMartin Pitt-4Victor Lowther [2009-11-30 18:14 -0600]:
<br>> That is exactly what I try to do, and performance is acceptable so
<br>> far (assuming the quirks are translated in advance). I will actually
<br>> profile it once I have reports from machines that actually require
<br>> quirks.
<br><br>Also, most machines nowadays will already be short-circuited by the
<br>"KMS || i915 || nvidia" check anyway, so it totally doesn't matter for
<br>them, too.
<br><br>Thanks!
<br><br>Martin
<br>--
<br>Martin Pitt | <a href="http://www.piware.de" target="_top" rel="nofollow">http://www.piware.de</a><br>Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587887&i=0" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26587428Re: hal 0.5.14 released2009-11-30T22:54:27Z2009-11-30T22:54:27ZRobby Workman-6On Tue, 01 Dec 2009 01:44:50 -0500
<br>Joe Marcus Clarke <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587428&i=0" target="_top" rel="nofollow">marcus@...</a>> wrote:
<br><br>> This will tell me if it compiles, but not if it will work on FreeBSD.
<br>> It should, though.
<br><br>After applying the patch (to 0.5.14 released sources) and running
<br>autoreconf, I get this:
<br><br> configure: error: conditional "HAVE_LIBUSB20" was never defined.
<br> Usually this means the macro was only invoked conditionally.
<br><br>-RW
<br><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587428&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (205 bytes) <a href="http://old.nabble.com/attachment/26587428/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26587499Re: hal 0.5.14 released2009-11-30T22:44:50Z2009-11-30T22:44:50ZJoe Marcus Clarke-2On Tue, 2009-12-01 at 00:39 -0600, Robby Workman wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On Tue, 01 Dec 2009 01:34:39 -0500
<br>> Joe Marcus Clarke <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587499&i=0" target="_top" rel="nofollow">marcus@...</a>> wrote:
<br>>
<br>> > On Tue, 2009-12-01 at 00:03 -0600, Robby Workman wrote:
<br>> > > On Mon, 30 Nov 2009 23:49:57 -0600
<br>> > > Robby Workman <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587499&i=1" target="_top" rel="nofollow">rw@...</a>> wrote:
<br>> > >
<br>> > > > On Mon, 30 Nov 2009 23:38:07 +0100
<br>> > > > Martin Pitt <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587499&i=2" target="_top" rel="nofollow">martin.pitt@...</a>> wrote:
<br>> > > >
<br>> > > > > Requirements for HAL 0.5.14 did not change since the last
<br>> > > > > release.
<br>> > > >
<br>> > > >
<br>> > > > Hrm... maybe I'm missing something obvious here, but after
<br>> > > > configure, I get this:
<br>> > > >
<br>> > > > use libusb: no
<br>> > > >
<br>> > > >
<br>> > > > The usb-specific lines in configure output are:
<br>> > > >
<br>> > > > checking for /usr/share/usb.ids... yes
<br>> > > > configure: WARNING: autodetected usb.ids in /usr/share
<br>> > > > checking usb.h usability... yes
<br>> > > > checking usb.h presence... yes
<br>> > > > checking for usb.h... yes
<br>> > > > checking for usb_find_devices in -lusb... yes
<br>> > > > checking for libusb20_dev_get_info in -lusb... no
<br>> > > >
<br>> > > > It appears that *maybe* this libusb20_dev_get_info is specific to
<br>> > > > freebsd, but config.log says my HALD_BACKEND=linux (as it should).
<br>> > > > So... what am I missing here? This is with libusb-1.0.6 and
<br>> > > > libusb-compat-0.1.3 installed.
<br>> > >
<br>> > >
<br>> > > CC'ing Joe Marcus Clarke, as I *think* this is related to the
<br>> > > new USB20 stuff for freebsd. I just build 0.5.12 and 0.5.13
<br>> > > on the same system, and libusb was enabled successfully without
<br>> > > the check for libusb20_dev_get_info at all.
<br>> >
<br>> > Yes, libusb20 is only for FreeBSD. I think what you're seeing is
<br>> > cosmetic, and USB support is being properly enabled (as the FreeBSD
<br>> > code overrides USE_LIBUSB after the Linux code consumes it). This
<br>> > shouldn't be hard to fix, though. I have a fix, but I won't be able
<br>> > to test it until this weekend.
<br>>
<br>>
<br>> I "fixed" it by hacking configure here, as I'm not inclined
<br>> (or likely even capable) ;-) of wading through too much
<br>> autotools stuff, but if you've got something to test, I'll
<br>> be happy to test it here and let you know - I keep a local
<br>> git tree anyway.
</div></div>This will tell me if it compiles, but not if it will work on FreeBSD.
<br>It should, though.
<br><br>Joe
<br><br>--
<br>PGP Key : <a href="http://www.marcuscom.com/pgp.asc" target="_top" rel="nofollow">http://www.marcuscom.com/pgp.asc</a><br><br /><tt>[usb.diff]</tt><br /><hr align="left" width="300" /><tt>diff --git a/configure.in b/configure.in
<br>index a8fda51..177b6e8 100644
<br>--- a/configure.in
<br>+++ b/configure.in
<br>@@ -479,9 +479,6 @@ if test "x$with_libpci" != xno ; then
<br> fi
<br> AM_CONDITIONAL([HAVE_LIBPCI], [test "x$USE_LIBPCI" = "xyes"])
<br>
<br>-USE_LIBUSB20=no
<br>-USE_LIBUSB=no
<br>-LIBUSB20_LIBS=""
<br> AC_ARG_WITH([backend],
<br> AS_HELP_STRING([--with-backend=<name>],
<br> [backend to use (linux/solaris/freebsd/dummy)]),
<br>@@ -510,21 +507,24 @@ AM_CONDITIONAL(HALD_COMPILE_FREEBSD, [test x$HALD_BACKEND = xfreebsd], [Compilin
<br> AM_CONDITIONAL(HALD_COMPILE_SOLARIS, [test x$HALD_BACKEND = xsolaris], [Compiling for Solaris])
<br> AC_SUBST(HALD_BACKEND)
<br> if test "x$HALD_BACKEND" = "xfreebsd"; then
<br>+ USE_LIBUSB20=no
<br>+ USE_LIBUSB=no
<br>+ LIBUSB20_LIBS=""
<br> AC_CHECK_LIB([usb20], [libusb20_dev_get_info], [USE_LIBUSB20=yes], [USE_LIBUSB20=no])
<br>+ if test "x$USE_LIBUSB20" = "xno"; then
<br>+ AC_CHECK_LIB([usb], [libusb20_dev_get_info], [USE_LIBUSB=yes], [USE_LIBUSB=no])
<br>+ fi
<br>+ AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB20" = "xyes"])
<br>+ AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB" = "xyes"])
<br>+ if test "x$USE_LIBUSB20" = "xyes"; then
<br>+ AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libusb20])
<br>+ LIBUSB20_LIBS="-lusb20"
<br>+ elif test "x$USE_LIBUSB" = "xyes"; then
<br>+ AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libsub20])
<br>+ LIBUSB20_LIBS="-lusb"
<br>+ fi
<br>+ AC_SUBST(LIBUSB20_LIBS)
<br> fi
<br>-if test "x$USE_LIBUSB20" = "xno"; then
<br>- AC_CHECK_LIB([usb], [libusb20_dev_get_info], [USE_LIBUSB=yes], [USE_LIBUSB=no])
<br>-fi
<br>-AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB20" = "xyes"])
<br>-AM_CONDITIONAL([HAVE_LIBUSB20],[test "x$USE_LIBUSB" = "xyes"])
<br>-if test "x$USE_LIBUSB20" = "xyes"; then
<br>- AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libusb20])
<br>- LIBUSB20_LIBS="-lusb20"
<br>-elif test "x$USE_LIBUSB" = "xyes"; then
<br>- AC_DEFINE(HAVE_LIBUSB20, 1, [Set if we need libsub20])
<br>- LIBUSB20_LIBS="-lusb"
<br>-fi
<br>-AC_SUBST(LIBUSB20_LIBS)
<br>
<br> dnl DBUS API is subject to changes
<br> AC_DEFINE_UNQUOTED(DBUS_API_SUBJECT_TO_CHANGE, [], [DBUS API is subject to change])
<br></tt><hr align="left" width="300" /><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587499&i=3" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (203 bytes) <a href="http://old.nabble.com/attachment/26587499/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26587316Re: hal 0.5.14 released2009-11-30T22:39:05Z2009-11-30T22:39:05ZRobby Workman-6On Tue, 01 Dec 2009 01:34:39 -0500
<br>Joe Marcus Clarke <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587316&i=0" target="_top" rel="nofollow">marcus@...</a>> wrote:
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On Tue, 2009-12-01 at 00:03 -0600, Robby Workman wrote:
<br>> > On Mon, 30 Nov 2009 23:49:57 -0600
<br>> > Robby Workman <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587316&i=1" target="_top" rel="nofollow">rw@...</a>> wrote:
<br>> >
<br>> > > On Mon, 30 Nov 2009 23:38:07 +0100
<br>> > > Martin Pitt <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587316&i=2" target="_top" rel="nofollow">martin.pitt@...</a>> wrote:
<br>> > >
<br>> > > > Requirements for HAL 0.5.14 did not change since the last
<br>> > > > release.
<br>> > >
<br>> > >
<br>> > > Hrm... maybe I'm missing something obvious here, but after
<br>> > > configure, I get this:
<br>> > >
<br>> > > use libusb: no
<br>> > >
<br>> > >
<br>> > > The usb-specific lines in configure output are:
<br>> > >
<br>> > > checking for /usr/share/usb.ids... yes
<br>> > > configure: WARNING: autodetected usb.ids in /usr/share
<br>> > > checking usb.h usability... yes
<br>> > > checking usb.h presence... yes
<br>> > > checking for usb.h... yes
<br>> > > checking for usb_find_devices in -lusb... yes
<br>> > > checking for libusb20_dev_get_info in -lusb... no
<br>> > >
<br>> > > It appears that *maybe* this libusb20_dev_get_info is specific to
<br>> > > freebsd, but config.log says my HALD_BACKEND=linux (as it should).
<br>> > > So... what am I missing here? This is with libusb-1.0.6 and
<br>> > > libusb-compat-0.1.3 installed.
<br>> >
<br>> >
<br>> > CC'ing Joe Marcus Clarke, as I *think* this is related to the
<br>> > new USB20 stuff for freebsd. I just build 0.5.12 and 0.5.13
<br>> > on the same system, and libusb was enabled successfully without
<br>> > the check for libusb20_dev_get_info at all.
<br>>
<br>> Yes, libusb20 is only for FreeBSD. I think what you're seeing is
<br>> cosmetic, and USB support is being properly enabled (as the FreeBSD
<br>> code overrides USE_LIBUSB after the Linux code consumes it). This
<br>> shouldn't be hard to fix, though. I have a fix, but I won't be able
<br>> to test it until this weekend.
</div></div><br>I "fixed" it by hacking configure here, as I'm not inclined
<br>(or likely even capable) ;-) of wading through too much
<br>autotools stuff, but if you've got something to test, I'll
<br>be happy to test it here and let you know - I keep a local
<br>git tree anyway.
<br><br>-RW
<br><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587316&i=3" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (205 bytes) <a href="http://old.nabble.com/attachment/26587316/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26587345Experimental quirk handling in pm-utils2009-11-30T22:37:10Z2009-11-30T22:37:10ZVictor LowtherNothing official yet, but if anyone is interested I have a branch of
<br>pm-utils with native quirk handling integrated at
<br><br><a href="http://cgit.freedesktop.org/~vlowther/pm-utils/log/?h=native-quirk-db" target="_top" rel="nofollow">http://cgit.freedesktop.org/~vlowther/pm-utils/log/?h=native-quirk-db</a><br><br>You can pull the native-quirk-db branch from
<br>git://anongit.freedesktop.org/~vlowther/pm-utils and test it out.
<br><br>It works for me, but none of the system I own end up actually querying
<br>the quirk database. :)
<br><br>Feedback welcome.
<br><br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587345&i=0" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26587289Re: hal 0.5.14 released2009-11-30T22:34:39Z2009-11-30T22:34:39Zmarcus-11On Tue, 2009-12-01 at 00:03 -0600, Robby Workman wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On Mon, 30 Nov 2009 23:49:57 -0600
<br>> Robby Workman <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587289&i=0" target="_top" rel="nofollow">rw@...</a>> wrote:
<br>>
<br>> > On Mon, 30 Nov 2009 23:38:07 +0100
<br>> > Martin Pitt <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587289&i=1" target="_top" rel="nofollow">martin.pitt@...</a>> wrote:
<br>> >
<br>> > > Requirements for HAL 0.5.14 did not change since the last release.
<br>> >
<br>> >
<br>> > Hrm... maybe I'm missing something obvious here, but after configure,
<br>> > I get this:
<br>> >
<br>> > use libusb: no
<br>> >
<br>> >
<br>> > The usb-specific lines in configure output are:
<br>> >
<br>> > checking for /usr/share/usb.ids... yes
<br>> > configure: WARNING: autodetected usb.ids in /usr/share
<br>> > checking usb.h usability... yes
<br>> > checking usb.h presence... yes
<br>> > checking for usb.h... yes
<br>> > checking for usb_find_devices in -lusb... yes
<br>> > checking for libusb20_dev_get_info in -lusb... no
<br>> >
<br>> > It appears that *maybe* this libusb20_dev_get_info is specific to
<br>> > freebsd, but config.log says my HALD_BACKEND=linux (as it should).
<br>> > So... what am I missing here? This is with libusb-1.0.6 and
<br>> > libusb-compat-0.1.3 installed.
<br>>
<br>>
<br>> CC'ing Joe Marcus Clarke, as I *think* this is related to the
<br>> new USB20 stuff for freebsd. I just build 0.5.12 and 0.5.13
<br>> on the same system, and libusb was enabled successfully without
<br>> the check for libusb20_dev_get_info at all.
</div></div>Yes, libusb20 is only for FreeBSD. I think what you're seeing is
<br>cosmetic, and USB support is being properly enabled (as the FreeBSD code
<br>overrides USE_LIBUSB after the Linux code consumes it). This shouldn't
<br>be hard to fix, though. I have a fix, but I won't be able to test it
<br>until this weekend.
<br><br>Joe
<br><br>--
<br>Joe Marcus Clarke
<br>FreeBSD GNOME Team :: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587289&i=2" target="_top" rel="nofollow">gnome@...</a>
<br>FreeNode / #freebsd-gnome
<br><a href="http://www.FreeBSD.org/gnome" target="_top" rel="nofollow">http://www.FreeBSD.org/gnome</a><br><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587289&i=3" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (203 bytes) <a href="http://old.nabble.com/attachment/26587289/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26587093Re: hal 0.5.14 released2009-11-30T22:03:03Z2009-11-30T22:03:03ZRobby Workman-6On Mon, 30 Nov 2009 23:49:57 -0600
<br>Robby Workman <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587093&i=0" target="_top" rel="nofollow">rw@...</a>> wrote:
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On Mon, 30 Nov 2009 23:38:07 +0100
<br>> Martin Pitt <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587093&i=1" target="_top" rel="nofollow">martin.pitt@...</a>> wrote:
<br>>
<br>> > Requirements for HAL 0.5.14 did not change since the last release.
<br>>
<br>>
<br>> Hrm... maybe I'm missing something obvious here, but after configure,
<br>> I get this:
<br>>
<br>> use libusb: no
<br>>
<br>>
<br>> The usb-specific lines in configure output are:
<br>>
<br>> checking for /usr/share/usb.ids... yes
<br>> configure: WARNING: autodetected usb.ids in /usr/share
<br>> checking usb.h usability... yes
<br>> checking usb.h presence... yes
<br>> checking for usb.h... yes
<br>> checking for usb_find_devices in -lusb... yes
<br>> checking for libusb20_dev_get_info in -lusb... no
<br>>
<br>> It appears that *maybe* this libusb20_dev_get_info is specific to
<br>> freebsd, but config.log says my HALD_BACKEND=linux (as it should).
<br>> So... what am I missing here? This is with libusb-1.0.6 and
<br>> libusb-compat-0.1.3 installed.
</div></div><br>CC'ing Joe Marcus Clarke, as I *think* this is related to the
<br>new USB20 stuff for freebsd. I just build 0.5.12 and 0.5.13
<br>on the same system, and libusb was enabled successfully without
<br>the check for libusb20_dev_get_info at all.
<br><br>-RW
<br><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587093&i=2" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (205 bytes) <a href="http://old.nabble.com/attachment/26587093/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26587029Re: hal 0.5.14 released2009-11-30T21:49:57Z2009-11-30T21:49:57ZRobby Workman-6On Mon, 30 Nov 2009 23:38:07 +0100
<br>Martin Pitt <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587029&i=0" target="_top" rel="nofollow">martin.pitt@...</a>> wrote:
<br><br>> Requirements for HAL 0.5.14 did not change since the last release.
<br><br><br>Hrm... maybe I'm missing something obvious here, but after configure,
<br>I get this:
<br><br> use libusb: no
<br><br><br>The usb-specific lines in configure output are:
<br><br> checking for /usr/share/usb.ids... yes
<br> configure: WARNING: autodetected usb.ids in /usr/share
<br> checking usb.h usability... yes
<br> checking usb.h presence... yes
<br> checking for usb.h... yes
<br> checking for usb_find_devices in -lusb... yes
<br> checking for libusb20_dev_get_info in -lusb... no
<br><br>It appears that *maybe* this libusb20_dev_get_info is specific to
<br>freebsd, but config.log says my HALD_BACKEND=linux (as it should).
<br>So... what am I missing here? This is with libusb-1.0.6 and
<br>libusb-compat-0.1.3 installed.
<br><br>-RW
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26587029&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26584596Re: Migrating suspend quirks away from hal2009-11-30T16:14:58Z2009-11-30T16:14:58ZVictor LowtherOn Nov 30, 2009, at 9:00 AM, Martin Pitt <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26584596&i=0" target="_top" rel="nofollow">martin.pitt@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> Hello Victor,
<br>>
<br>> Victor Lowther [2009-11-25 8:43 -0600]:
<br>>> No, it translates the .fdi files that are currently on the system
<br>>> into a
<br>>> native format that uses bash-style extended regular expressions
<br>>> instead of
<br>>> the .fdi ad-hoc pattern matching scheme.
<br>>
<br>> Ah, got it now. Since I am using KMS, the original script didn't write
<br>> out the translated files.
</div><br>:)
<br><div class='shrinkable-quote'><br>>
<br>>> No need, I already do that in the current script for convienence.
<br>>> Once we
<br>>> actually decide that this is the way forward, moving the XML
<br>>> translation
<br>>> into its own script or rewriting it in a language that actually
<br>>> understands
<br>>> XML will be pretty easy.
<br>>
<br>> I don't think that the translation script matters much. As long as it
<br>> is correct for the current set of quirks, it just needs to work once,
<br>> and from then on we keep maintaining the quirks DB in the new format,
<br>> in pm-utils itself. As already discussed, the current quirks DB is by
<br>> and large stable, for a lot of legacy hardware, so it won't change
<br>> that often.
<br>>
<br>> A more interesting question is the performance of parsing/evaluating
<br>> the native files. They seem pretty verbose to me, but as long as you
<br>> only use bash commands/operations and avoid calling an external
<br>> program for each line, it shouldn't actually matter much.
</div><br>That is exactly what I try to do, and performance is acceptable so far
<br>(assuming the quirks are translated in advance). I will actually
<br>profile it once I have reports from machines that actually require
<br>quirks.
<br><br>> Also, the file format and performance optimizations can then be done
<br>> easily, since they are an internal implementation detail of pm-utils
<br>> and don't affect anything else.
<br><br>Indeed.
<br><br>> So, what do you think about committing the generated quirks into
<br>> pm-utils and removing the hal bits? Then we can ask submitters of new
<br>> quirks to report them to pm-utils first, instead of/in addition to
<br>> committing them to hal.
<br><br>It will do for the short term.
<br><br>> I just had a look at hal-info commit history, and we had some 30
<br>> quirks additions in 2009, and only one in the last three months.
<br><br>Cool. I should have a branch of pm-utils with native quirk db handling
<br>(but not the native quirkdb, just the translator) out soon for testing
<br>in the fd.o git repo soon.
<br><br>> Thanks,
<br>>
<br>> Martin
<br>>
<br>> --
<br>> Martin Pitt | <a href="http://www.piware.de" target="_top" rel="nofollow">http://www.piware.de</a><br>> Ubuntu Developer (www.ubuntu.com) | Debian Developer
<br>> (www.debian.org)
<br>_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26584596&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br>tag:old.nabble.com,2006:post-26583479hal-info 20091130 released2009-11-30T14:48:13Z2009-11-30T14:48:13ZMartin Pitt-4Hello all,
<br><br>while we are at releasing anyway, I also did a new hal-info snapshot:
<br><br><a href="http://hal.freedesktop.org/releases/hal-info-20091130.tar.gz" target="_top" rel="nofollow">http://hal.freedesktop.org/releases/hal-info-20091130.tar.gz</a><br> md5: 34375489a02a00b250fdc0b280be11b8
<br> sha1: d548a0d837d39a609c42a789c92578150c18b9f5
<br><br><a href="http://hal.freedesktop.org/releases/hal-info-20091130.tar.bz2" target="_top" rel="nofollow">http://hal.freedesktop.org/releases/hal-info-20091130.tar.bz2</a><br> md5: 995b8d2dbfb0646b07c92bb8d23cbcf1
<br> sha1: 5d6a34020942a388277e4edf95c077656fecc854
<br><br>Martin
<br>--
<br>Martin Pitt | <a href="http://www.piware.de" target="_top" rel="nofollow">http://www.piware.de</a><br>Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
<br><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26583479&i=0" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (204 bytes) <a href="http://old.nabble.com/attachment/26583479/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26583329hal 0.5.14 released2009-11-30T14:38:00Z2009-11-30T14:38:00ZMartin Pitt-4"Dave, this conversation can serve no purpose anymore. Goodbye."
<br><br>Hello world,
<br><br>As promised, I did a new hal release to collect the rather large
<br>number of fixes that hit trunk recently. This will probably be the
<br>last hal release that will happen from the Linux side.
<br><br><a href="http://hal.freedesktop.org/releases/hal-0.5.14.tar.gz" target="_top" rel="nofollow">http://hal.freedesktop.org/releases/hal-0.5.14.tar.gz</a><br> md5: e9163df591a6f38f59fdbfe33e73bf20
<br> sha1: 95bdc8141b0bce197d0d47f5bec491b08c6e3853
<br><br><a href="http://hal.freedesktop.org/releases/hal-0.5.14.tar.bz2" target="_top" rel="nofollow">http://hal.freedesktop.org/releases/hal-0.5.14.tar.bz2</a><br> md5: c627d8fb0f9afff94f3c687b5216bc06
<br> sha1: a6ec098d78112e18e2773afa5f9ed642b00c4c59
<br><br>Requirements for HAL 0.5.14 did not change since the last release.
<br><br>Thanks to all contributors!
<br><br>Martin
<br><br><br>Arnout Vandecappelle (1):
<br> don't remove scsi_host if there are still targets using it
<br><br>Aurelien Jarno (2):
<br> Fix build failure on GNU/kFreeBSD
<br> generalize keyboard detection code for FreeBSD
<br><br>C. Scott Ananian (1):
<br> remove action_parameters from DBus XML for IsCallerPrivileged
<br><br>Danny Kukawka (40):
<br> fixed commit 36d076bf26350e022731cb7c2c9f4e840dd25e37
<br> move ssb bus code to the correct place
<br> add SSB bus to SPEC
<br> cleanup: don't set udi manually if hal_device_set_udi() was used
<br> add IBM Ebus to SPEC
<br> hide more MBR, bootstrap and other partitions from desktop
<br> fix code doc for resolve_udiprop_path()
<br> hald_dbus.c: fix DBusError handling
<br> hald_runner.c: fix usage of DBusError
<br> ci-tracker.c: fix usage of DBusError
<br> ck-tracker.c: fix usage of DBusError
<br> more DBusError fixes
<br> another DBusError fix
<br> fix configure to get --disable-console-kit working
<br> fix probe-ieee1394-unit.c DBusError and LibHalContext handling
<br> fix DBusError handling in probe directory
<br> free string after usage
<br> fix usage of deprected g_io_channel_seek()
<br> replace deprecated g_basename() with g_path_get_basename()
<br> replace another deprecated g_basename() with g_path_get_basename()
<br> replace deprecated g_strcasecmp() with g_ascii_strcasecmp()
<br> fix DBusError handling in linux addon directory
<br> Merge branch 'master' of ssh://<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26583329&i=0" target="_top" rel="nofollow">dkukawka@...</a>/git/hal
<br> fix compiler warning in libhal-storage
<br> fix commit 141ca8cd7b768ddefa1bfaa563cbef4337e32b7c
<br> extend debug message in device_reprobe()
<br> fix hotplug_event_process_queue() to get reprobe working
<br> handle keyboard backlight leds via org.freedesktop.Hal.Device.KeyboardBacklight
<br> changed massif-hald.sh to work the same way as run-hald.sh
<br> changed valgrind-hald.sh to write a logfile
<br> fix memory leaks due to usage of g_path_get_basename()
<br> add hald/valgrind.log to .gitignore
<br> fix memory leak in acpi_button_add() in error case
<br> fix memory leak due to usage of g_strdup()
<br> fix DBusError handling in freebsd code
<br> adopted version of commit 122e41a10 to fix docking stations
<br> add keyboard_backlight.* and *.num_levels to led class
<br> update SPEC with kbd_backlight(.*) and leds.num_levels
<br> always set leds.num_levels since it's mandatory
<br> add a check for leds.num_levels to addon-leds.c
<br><br>Dmitry Torokhov (1):
<br> Correctly identify touchpads
<br><br>Drew Moseley (1):
<br> add libhal_device_property_remove_watch_all() to libhal
<br><br>Frederic Crozat (1):
<br> hide Windows recovery partitions on pre-installed Futjisu laptops
<br><br>Joe Marcus Clarke (17):
<br> re-enable libvolume_id support for FreeBSD
<br> add USB2 support to the FreeBSD backend
<br> add support for reading ufsids
<br> add some missing storage properties
<br> add USB2 support
<br> fix support for power and brightness management
<br> fix a problem building the FreeBSD backend
<br> add USB2 support
<br> add support for mouse device probing
<br> add support for Fuse mounts
<br> add support for newer GEOM types
<br> add support for polling of mouse devices
<br> add missing LDADD and CFLAGS for addon-mouse.c
<br> add locking support to the storage addon
<br> update time handling functions
<br> ignore probe devices
<br> fix DBusError handling and a memory leak
<br><br>Johannes Hessellund (1):
<br> read brightness from actual_brightness and not from brightness
<br><br>Kay Sievers (1):
<br> configure.in: require blkid >= 2.15 from util-linux-ng
<br><br>Maciej Grela (1):
<br> Remove the 512 byte limit for PATH in hald.c
<br><br>Martin Poole (1):
<br> Fix a segfault in the mdraid code -- see rh#507782 for more info
<br><br>Michael Biebl (7):
<br> Make libhald_freebsd_probe.la a noinst library.
<br> fix a misleading warning in ondemand_set_consider_nice()
<br> Fix a crasher in hal_util_get_last_element
<br> Fix unconditional usage of PATH_MAX
<br> Support relative paths in umount.hal
<br> list "relatime" as valid mount option on Linux.
<br> Fix build failures with binutils-gold
<br><br>--
<br>Martin Pitt | <a href="http://www.piware.de" target="_top" rel="nofollow">http://www.piware.de</a><br>Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
<br><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26583329&i=1" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (204 bytes) <a href="http://old.nabble.com/attachment/26583329/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26582769Re: 0.5.14 release in two weeks?2009-11-30T14:01:54Z2009-11-30T14:01:54ZMartin Pitt-4Helly Dmitry,
<br><br>Dmitry Torokhov [2009-11-05 23:47 -0800]:
<br>> BTN_TOUCH (as well as ABS_PRESSURE) is used not only by touchpads but
<br>> by touchscreens as well. The proper ceck for a touchpad is presence
<br>> of BTN_TOOL_FINGER and absence of BTN_TOOL_PEN (the latter to filter
<br>> out some tablets that use BTN_TOOL_FINGER).
<br>>
<br>> Tablet matching should be on either BTN_TOOL_PEN or BTN_STULYS.
<br><br>Thanks! This seems to work well, applied.
<br><br>Martin
<br><br>--
<br>Martin Pitt | <a href="http://www.piware.de" target="_top" rel="nofollow">http://www.piware.de</a><br>Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
<br><br /> <br />_______________________________________________
<br>hal mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26582769&i=0" target="_top" rel="nofollow">hal@...</a>
<br><a href="http://lists.freedesktop.org/mailman/listinfo/hal" target="_top" rel="nofollow">http://lists.freedesktop.org/mailman/listinfo/hal</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (204 bytes) <a href="http://old.nabble.com/attachment/26582769/0/signature.asc" target="_top">Download Attachment</a></div>