From owner-freebsd-acpi@FreeBSD.ORG Wed May 7 15:49:15 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A95A960; Wed, 7 May 2014 15:49:15 +0000 (UTC) Received: from mail.atelo.org (atelo.org [192.95.27.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03BD3985; Wed, 7 May 2014 15:49:14 +0000 (UTC) Received: from coyotlan.Tlalpan (ovo.atelo.org [192.168.1.7]); by mail.atelo.org (OpenSMTPD) with ESMTP id 9485b100; Wed, 7 May 2014 15:48:35 +0000 (UTC) Received: from localhost (1001@localhost [local]); by localhost (OpenSMTPD) with ESMTPA id 9d2e5814; Wed, 7 May 2014 08:48:55 -0700 (PDT) Date: Wed, 7 May 2014 08:46:07 -0700 From: =?utf-8?B?WMSrY8Oy?= To: Lars Engels Subject: Re: Emitting keyboard events Message-ID: <20140507154607.GA1826@coyotlan.Tlalpan> References: <20140501205706.GA6007@coyotlan.Tlalpan> <20140507135117.GL1451@e-new.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140507135117.GL1451@e-new.0x20.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: rpaulo@freebsd.org, "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:49:15 -0000 On Wed, May 07, 2014 at 03:51:17PM +0200, Lars Engels wrote: > IIRC Rui (CC'ed) did some work on implementing new ACPI key events in > acpi_asus for the first EeePC. Looking around the acpi drivers, some hard-encode actions associated to the events (like brightness control), some emit messages for devd (like sound control for the asus), and most mix the two options. Emitting devd events is both easy and highly user configurable. But it still does not solve the problem of reinjecting the special keys as generic keyboard events, for instance to let the user configure them through xorg. Writing a virtual keyboard in each acpi driver seems a lot of duplication, and maybe too heavy. IMHO acpi drivers should just emit information to be caught by devd. Maybe with a single format, so that a shared other component can listen to them and reinject them as generic keyboard events.