Proper creation of /dev/apm_bios
Background for debian-devel:
On certain (many?) machines, the new X packages will cause the console to
completely hang after waking back up from being put to sleep. This can be
fixed by having /dev/apm_bios and appropriate kernel support. The
powermgmt-base package does this, but on PowerPC, it is not installed by
default, leaving PowerPC laptops in a situation where they are easily hung
On Wed, Oct 30, 2002 at 11:32:09PM -0500, Branden Robinson wrote:
> > Perhaps the bug is not with X, but I submit that it is still a bug.
> Well, why don't you go ask debian-devel what package should handle this
> sort of thing?
> > If these lockups are occuring becuase there is no /dev/apm_bios,
> > couldn't X's postinst at least create it?
> Why shouldn't the makedev package?
That would be fine too -- even ideal. Or a dep on powermgmt-base by
domething. Powermgmt-base appears to be better because it also handles
devfs, though I'm not familiar enough with devfs to know exactly what that
> > Interestingly, powermgmt-base presents a question about this. On x86
> > machines, apmd depends on this package, but nothing does on powerpc.
> > Perhaps xserver-xfree86 should do so, to ensure that proper power management
> > interfaces are available to userland?
> And what of people using other X server packages, or with no X server at
> all? Shall we just assume those folks don't need power management
To date, xserver-xfree86 is the only package I have observed that fails
catastrophically without /dev/apm_bios. Most others work with entries in
/proc. However I'm certainly fine with having it done on a more global
> > powermgmt-base also appears to take care of the situation properly for
> > people using devfs. Moreover, its size is 128K installed and depends
> > only on makedev, libc6, and debconf. It should not pose any problem
> > for the X server.
> Sounds like you have a problem with Debian's PowerPC architecture
> support, and not a problem with XFree86 at all.
Could be; like I said, knowing the info in this bug's history, I agree that
it may not be a bug in X. I just disagree with your decision to close it,
and feel that it is still a bug that perhaps needs to be reassigned.