From patchwork Thu Aug 2 13:46:12 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luca Tettamanti X-Patchwork-Id: 1267521 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 3342EDF223 for ; Thu, 2 Aug 2012 13:46:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754722Ab2HBNqU (ORCPT ); Thu, 2 Aug 2012 09:46:20 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:57542 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754449Ab2HBNqT (ORCPT ); Thu, 2 Aug 2012 09:46:19 -0400 Received: by wgbdr13 with SMTP id dr13so7979823wgb.1 for ; Thu, 02 Aug 2012 06:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=qPORLObPbYwSK8oBVzoPAZrvqXV+GFvW9sP3qNLzlMI=; b=pbcDemVXm0nI7Cj2PBxZFi9pM3Ztt4OhPdngUG1bfID/Od/TvE+WKqZCH0faT9/Ykc Ht/C9jV/E80IChtd9urAMbztRm6C35m9X6g/JvSFobWoBSt7iRiIYDn0cs3FrI/ysbBL 4vsWVPSCcZSy3jXHxl0Jf+gHf0YskC5FRjB4Bh+YTRlAEqxi2r8juPgCdov4qjY0uSd+ jiZ5TCQaxdlu1L4X/PP9IRJ9G+3xr0CxHD+CeLg2CELsttOm4eN/xVY3Oh7VKv4V3UNb fUD9cfemJNrBHXrElASd1cWuzUIok0yP+hwt3Th4ngq7GWMsVzZFGUhGbKkIV4o9koG0 e2fw== Received: by 10.180.86.226 with SMTP id s2mr4918336wiz.9.1343915178029; Thu, 02 Aug 2012 06:46:18 -0700 (PDT) Received: from growl (seco.como.polimi.it. [131.175.57.192]) by mx.google.com with ESMTPS id h9sm33713052wiz.1.2012.08.02.06.46.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 06:46:17 -0700 (PDT) Date: Thu, 2 Aug 2012 15:46:12 +0200 From: Luca Tettamanti To: Zhang Rui Cc: Alex Deucher , airlied@gmail.com, dri-devel@lists.freedesktop.org, Alex Deucher , joeyli , linux-acpi@vger.kernel.org, Len Brown Subject: Re: [PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events Message-ID: <20120802134612.GA30802@growl> References: <20120729130644.GA12378@growl> <20120730202449.GA5600@growl> <20120731200520.GA5425@growl> <20120801134900.GA7909@growl> <1343868330.1682.502.camel@rui.sh.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1343868330.1682.502.camel@rui.sh.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote: > On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote: > > AMD ACPI interface may overload the standard event > > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such > > cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the > > userspace because the user did not press the mode switch key (the > > spurious keypress confuses the DE which usually changes the > > display configuration and messes up a dual-screen setup). > > This patch gives the radeon driver the chance to examine the event and > > block the keypress if the event is an "AMD event". > > > > Signed-off-by: Luca Tettamanti > > --- > > Any comment from ACPI front? > > > it looks good to me. > But I'm wondering if we can use the following code for ACPI part, which > looks cleaner. > I know this may change the behavior of other events, but in theory, we > should not send any input event if we know something wrong in kernel. > > what do you think? I like it, it's cleaner. I've split the patch in two pieces (one for video, the other for radeon) and adopted your suggestion. BTW, I'm leaving for vacation in a few hours, I'll be offline till mid August. Luca From acce30c96b90d1bc550e82a9e7f19226fa194d5e Mon Sep 17 00:00:00 2001 From: Luca Tettamanti Date: Thu, 2 Aug 2012 15:30:27 +0200 Subject: [PATCH 1/2] ACPI video: allow events handlers to veto the keypress The standard video events may be overloaded for device specific purposes. For example AMD ACPI interface overloads ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the userspace because the user did not press the mode switch key (the spurious keypress confuses the DE which usually changes the display configuration and messes up a dual-screen setup). This patch gives the handlers the chance to examine the event and block the keypress if the event is device specific. v2: refactor as suggested by Zhang Rui Signed-off-by: Luca Tettamanti Acked-by: Zhang Rui --- drivers/acpi/video.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 1e0a9e1..d75642a 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -1448,8 +1448,7 @@ static void acpi_video_bus_notify(struct acpi_device *device, u32 event) case ACPI_VIDEO_NOTIFY_SWITCH: /* User requested a switch, * most likely via hotkey. */ acpi_bus_generate_proc_event(device, event, 0); - if (!acpi_notifier_call_chain(device, event, 0)) - keycode = KEY_SWITCHVIDEOMODE; + keycode = KEY_SWITCHVIDEOMODE; break; case ACPI_VIDEO_NOTIFY_PROBE: /* User plugged in or removed a video @@ -1479,8 +1478,9 @@ static void acpi_video_bus_notify(struct acpi_device *device, u32 event) break; } - if (event != ACPI_VIDEO_NOTIFY_SWITCH) - acpi_notifier_call_chain(device, event, 0); + if (acpi_notifier_call_chain(device, event, 0)) + /* Something vetoed the keypress. */ + keycode = 0; if (keycode) { input_report_key(input, keycode, 1);