On Jan 12, Mattia Dongili <malattia@linux.it> wrote: > No. That's the kernel only supporting a single reader for /proc/acpi/event. > I'm cooking a patch to support multiple readers (based on an old and never > applied patch) but I doubt it will be accepted mainline. > /proc/acpi/event contention has _always_ been a problem and the only > solution is to support multiple readers, not to require acpid's socket, > that's just ridiculous :) It's not up to you to decide that a kernel interface is wrong, at least without the ACPI maintainer agreeing. Arguing that this will be fixed by a kernel patch which does not exist and will probably be rejected (and even if it were accepted would be in Debian kernels in a 2-4 months timeframe) is not acceptable, this needs to be fixed in X (I suggest by retrying to open the socket if it worked the first time). "breaks unrelated software" is one of the criteria for critical bugs, and even if 6.9 needs to move to testing ASAP it's not a reason to take this bug lightly. > With my patch if acpid dies xorg reopens /proc/acpi/event. > > So, I'd say this is either an acpid bug (start earlier?) or better yet a > kernel bug. Wrong, because acpid is normally restarted during the X server life cycle (on upgrades and by logrotate) so X needs to cope with it. -- ciao, Marco
Attachment:
signature.asc
Description: Digital signature