On Fri, 2015-02-06 at 14:23 +0200, Aleksandr Rybalko wrote:
> On Wed, 04 Feb 2015 22:56:57 +0100
> Michal Varga <michal.va...@stonehenge.sk> 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:


At lines 500-528, all cases got their own sysctls so you can easily turn
their behavior on/off:

  case SPCLKEY | XXXX:
    if (vt_XXXX) ...
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

If that's ok with you and you're interested, I could submit a patch via
PR for review...


Michal Varga,

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to