Date: Thu, 02 Nov 2006 23:29:29 -0500 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Kevin Oberman <oberman@es.net> Cc: gnome@freebsd.org Subject: Re: HAL taking over Message-ID: <1162528169.8125.3.camel@shumai.marcuscom.com> In-Reply-To: <20061103035349.10D0745054@ptavv.es.net> References: <20061103035349.10D0745054@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-Yuo/X0bkkZ2Q0dchBNFa Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2006-11-02 at 19:53 -0800, Kevin Oberman wrote: > > From: Joe Marcus Clarke <marcus@marcuscom.com> > > Date: Thu, 02 Nov 2006 20:52:04 -0500 > >=20 > > On Thu, 2006-11-02 at 14:39 -0800, Kevin Oberman wrote: > > > HAL looks wonderful, but it seems to be trying to take control of my > > > system.=20 > > >=20 > > > I have my system set up to ignore the lid switch > > > (hw.acpi.lid_switch_state: NONE) > > >=20 > > > When I have HALD running, it suspends my system, anyway, and it does = not > > > resume. It reboots. > >=20 > > You will have to ignore the lid button in HAL. Basically, create > > a /usr/local/share/hal/fdi/preprobe/20thirdparty/10-acpi-lid.fdi file > > with the following contents then restart hald: > >=20 > > <?xml version=3D"1.0" encoding=3D"UTF-8"?> > > <deviceinfo version=3D"0.2">=20 > > <device>=20 > > <!-- ignore ACPI lid buttons --> > > <match key=3D"button.type" string=3D"lid"> > > <merge key=3D"info.ignore" type=3D"bool">true</merge> > > </match> > > </device> > > </deviceinfo> > >=20 > > If that still doesn't work, HAL may need a patch to support ignoring > > these kind of events. > >=20 > > >=20 > > > When I have HALD running, I can no longer unmount disks. I can't do i= t > > > from the command line (volume busy) or from nautilus (Not authorized)= . > >=20 > > Which disks? Volumes mounted by HAL can be controlled with the > > gnome-mount command provided you have appropriate access (see > > http://www.freebsd.org/gnome/docs/faq2.html#q19 ). > >=20 > > >=20 > > > I suspect HALD can be configured to make all of this work right, but = I > > > don't know quite where to look. (OK, I have some hints on the unmount= ing > > > issue, but I have not gotten it to work yet. > > >=20 > > > Finally, the disks are no longer labeled in a meaningful fashion. Wha= t > > > used to be the "D" drive on my system is now showing up as "7.8 GB". = Not > > > too useful and made a bit worse because I often mount two partitions = of > > > almost exactly the same size. > >=20 > > You can label volumes using tunefs -L. After doing this, they should > > appear with more meaningful names. >=20 > Mixed success. First, The big one...the XML for the lid worked > perfectly. I can now close the lid without suspending! >=20 > The disk labeling was a mixed bag. One partition showed up with it's > label and one did not. The third is a FAT slice, so I don't really > expect it to work (and was afraid to try). If I label it under Windows, > will that label be read by HAL? Yes. >=20 > The partition that did not show a label looks fine when I do a dumpfs on > it, so the tunefs did the trick. You need to restart hald, and re-login to GNOME for this to take effect. lshal should show a volume.label property with your label. If it does not, then gnome-vfs will not show a name. > > dumpfs /dev/ad2s1 > magic 19540119 (UFS2) time Mon Jul 3 11:27:14 2006 > superblock location 65536 id [ 44a8d938 cf608db3 ] > ncg 4 size 262144 blocks 253815 > bsize 16384 shift 14 mask 0xffffc000 > fsize 2048 shift 11 mask 0xfffff800 > frag 8 shift 3 fsbtodb 2 > minfree 8% optim time symlinklen 120 > maxbsize 16384 maxbpg 2048 maxcontig 8 contigsumsize 8 > nbfree 29311 ndir 42 nifree 64765 nffree 1733 > bpg 8193 fpg 65544 ipg 16448 > nindir 2048 inopb 64 maxfilesize 140806241583103 > sbsize 2048 cgsize 12288 csaddr 2112 cssize 2048 > sblkno 40 cblkno 48 iblkno 56 dblkno 2112 > cgrotor 0 fmod 0 ronly 0 clean 1 > avgfpdir 64 avgfilesize 16384 > flags none > fsmnt / > volname aux swuid 0 >=20 > If I select "Properties", nautilus crashes. (No, no dump or backtrace at > this time.) I cannot reproduce. You will need to get a backtrace with debugging symbols. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-Yuo/X0bkkZ2Q0dchBNFa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFSsWpb2iPiv4Uz4cRAg53AJ9CufxT4tPwB6gUXwhA/ZY0Nx/qlwCfaUDE Wn76rzov3X+tZ4Vy2S7pD+Y= =TNHx -----END PGP SIGNATURE----- --=-Yuo/X0bkkZ2Q0dchBNFa--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1162528169.8125.3.camel>