From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 18:51:23 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88927650 for ; Fri, 6 Feb 2015 18:51:23 +0000 (UTC) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39176C8B for ; Fri, 6 Feb 2015 18:51:23 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so4600079wib.1 for ; Fri, 06 Feb 2015 10:51:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:content-type:mime-version :content-transfer-encoding; bh=VZcN45tz6hAloZAvgAa5kCY1QsbCv5xQisbokZZC7eM=; b=jeaUZALr6isaEhx1aoUME8qd/clhRyoAc5HSkvM6LALTuPaWC0XVI1CEEyW+72Vx0S aNxwAqACRWfaVJTiXvSaOJF6m/ymJkV07lySOWYtSCSAHtQbigqr0FHy4SyMhCzOjsWL djgyRiHzR2jQjizetldGGkboglYrGuYZRQto5sGNDySXy8XqRJ4ACjaRC534EVoR6PUO i4M9p9gZXv9yt5VKQxqP4PMH7mFf8GkEAIADx2YzKV1Io7qjhMa6NWlKo+Fut3zSGhBN qcM7XXdusYewwC2GNwu5E2vF9HGhJV28Po2vFfFGrTFwL5qizjHUzuNmmpaZT2WmT7WZ qoSg== X-Gm-Message-State: ALoCoQkEKeobgLRolmW+UIvb5E2Yz2zlcs9/Cx1owBCTnB2lex8qC2FlDDjHLPC7qjLi/I3QT9Jr X-Received: by 10.194.175.202 with SMTP id cc10mr10461930wjc.27.1423248177241; Fri, 06 Feb 2015 10:42:57 -0800 (PST) Received: from xenon (105.42.broadband6.iol.cz. [88.101.42.105]) by mx.google.com with ESMTPSA id bv6sm4421826wjb.30.2015.02.06.10.42.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2015 10:42:56 -0800 (PST) Message-ID: <1423248174.885.30.camel@stonehenge.sk> Subject: Re: vt(4) sysctl inconsistency question From: Michal Varga To: Aleksandr Rybalko Date: Fri, 06 Feb 2015 19:42:54 +0100 In-Reply-To: <20150206142312.2a9935dc58796e88be92205f@freebsd.org> References: <1423087017.854.20.camel@stonehenge.sk> <20150206142312.2a9935dc58796e88be92205f@freebsd.org> Organization: Stonehenge Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.10 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 18:51:23 -0000 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 | 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 them. If that's ok with you and you're interested, I could submit a patch via PR for review... m. -- Michal Varga, Stonehenge