On Fri, 2015-02-06 at 14:23 +0200, Aleksandr Rybalko wrote:
> On Wed, 04 Feb 2015 22:56:57 +0100
> Michal Varga wrote:
>> [...]
> > Interestingly, two cases in particular (excluding SPSC which isn't
> > implemented yet) were left out of this configuration, namely the standby
> > and suspend modes (STBY, SUSP), making use of those keys completely
> > non-optional.
> >
> > If anyone could tell me, what was the reason for not including sysctls
> > for those two modes?
> >
> > m.
> >
> Hi Michal!
>
> When I was work on vt(4) due to lack of knowledge about kbd(4)
> internals I decide to not touch it a lot, so I mostly just copy sc(4)
> things :)
>
> IIRC support of such keys/combinations will require some updates to
> kbd(4).
>
> Think, if somebody will prepare patch for such things, guys and maybe
> me, will be happy to review and possibly commit it.
>
> Thanks!
Hello Aleksandr,
I think you misunderstood what I meant. The code in question is already
there, just that some particular cases are not configurable via sysctl:
http://svnweb.freebsd.org/base/head/sys/dev/vt/vt_core.c?r1=271380&r2=271381&;
At lines 500-528, all cases got their own sysctls so you can easily turn
their behavior on/off:
case SPCLKEY | :
if (vt_) ...
The other three cases (l. 530-540), one of them unfinished though, are
missing sysctls, so vt will always execute those actions no matter what.
Now that you mentioned copying sc(4) stuff, I cross-checked it with sc
sources and you're right, even sc is missing configuration in cases like
suspend and standby (which is kinda puzzling, to me).
So now the question stands - can we have the rest of this behavior
configurable, or is there any opposition to it?
Which would mean adding another set of:
VT_SYSCTL_INT(kbd_saver, 1, "Enable screen saver keyboard combination."
VT_SYSCTL_INT(kbd_standby, 1, "Enable PM standby keyboard combination."
VT_SYSCTL_INT(kbd_suspend, 1, "Enable PM suspend keyboard combination."
and ading the corresponding 'if (vt_' to those cases that are missing
them.
If that's ok with you and you're interested, I could submit a patch via
PR for review...
m.
--
Michal Varga,
Stonehenge
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
