> > I'm not saying that the kernel shouldn't initialize the attributes or have a default. > But it should only set the default when the attribute is initialized (It doesn't > even matter to me whether it's enabled or disabled). > > It's just there should not be further manipulation from the kernel (e.g. > device_set_wakeup_enable) afterwards because 1. it's brings inconsistency > because the function is adopted per driver 2. it's a user preference and > responsibilty 3. third it prevent udev to apply a rule properly (regression / bug) > > P.S. Alan for my case, I don't need a patch for logitech-dj, I just need to remove > device_set_enable_wakeup from hid_core.c, then I can enable or disable the > attribute with a udev rule happily for both devices. > You may apply your choice no matter what the default value is, would you tell us why you can't do that? Peter > ▶ Show quoted text > On 23 April 2015 at 09:21, Peter Chen <Peter.Chen@xxxxxxxxxxxxx> wrote: > > > >> > > > >> > > Oh, okay, I didn't realize that. > >> > > > >> > > Is there a reasonable way to enable wakeup only when the driver > >> > > learns that a keyboard is connected? Where would the driver do this? > >> > > >> > I don't know if the driver ever "knows" this, as you can pair lots > >> > of different devices to this same receiver. There's a userspace > >> > application that lets you manage the device, called "solaar", that > >> > this option could be changed in. > >> > > >> > But really, putting the device to sleep should work for it no > >> > matter if this is a keyboard or a mouse or a joystick, as the > >> > wakeup logic is in the receiver, not in the device on the other end of the > wireless link. > >> > > >> > Turning autosuspend works for me for my mouse connected. It > >> > doesn't work for one of my "real" USB keyboards when it's connected > >> > to the machine, which is why I can't enable autosuspend for it, as > >> > it drives me crazy. > >> > > >> > I don't have a keyboard to test the receiver with at the moment, to > >> > see if autosuspend works for both things connected at the same > >> > time, or for just the keyboard. > >> > >> Tom and I have been talking about enabling wakeup, not autosuspend. > >> The question is whether or not the default wakeup setting for the > >> receiver should be "enabled". > >> > >> The kernel's policy is that keyboards should be enabled for wakeup, by > default. > >> I think that matches most people's expectations. But when you've got > >> a "universal" receiver, what then? > >> > >> Should it always be enabled by default because a keyboard _might_ be > >> connected? Should it be enabled only when a keyboard is detected? > >> What if multiple devices are connected at the same time? > >> > > > > From my point, the user option should not depend on kernel default value. > > If the system you build needs some USB devices as system wakeup > > source, the developers need to make sure the wakeups are enabled > > before system enters suspend. > > > > Peter > > > >> Shucks -- does the receiver even _work_ as a wakeup device? It > >> claims to, but that would require it to remain in wireless contact > >> with the remote keyboard even while it's supposed to be in a > >> low-power state, which rather seems to defeat the purpose. > >> > >> Alan Stern > >> > >> PS: I've got wakeup enabled for the PS/2 keyboard attached to the > >> computer I'm using now, but it doesn't work. I have to press the > >> power button to wake the machine up from suspend. Probably an issue > >> in the BIOS or ACPI -- I haven't bothered to try and track it down. > >> > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-usb" > >> in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo > >> info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
