From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752670AbdFUIgX (ORCPT ); Wed, 21 Jun 2017 04:36:23 -0400 Received: from mail.netline.ch ([148.251.143.178]:55981 "EHLO netline-mail3.netline.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752545AbdFUIgS (ORCPT ); Wed, 21 Jun 2017 04:36:18 -0400 Subject: Re: [Nouveau] [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set To: Peter Rosin , Philippe Cornu , =?UTF-8?Q?Christian_K=c3=b6nig?= , Yannick Fertre , Gerd Hoffmann , Daniel Vetter , Alex Deucher , Dave Airlie , Vincent Abriou , Ben Skeggs , Bartlomiej Zolnierkiewicz References: <1497986735-14418-1-git-send-email-peda@axentia.se> <1497986735-14418-2-git-send-email-peda@axentia.se> <20170621073804.akyg4rxvoavjjt2v@phenom.ffwll.local> <20170621081454.ymykfka5peelkqxp@phenom.ffwll.local> Cc: nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, virtualization@lists.linux-foundation.org, amd-gfx@lists.freedesktop.org, linux-fbdev@vger.kernel.org From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: <517b7144-9612-2249-cff6-cdebcb628f7b@daenzer.net> Date: Wed, 21 Jun 2017 17:36:08 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170621081454.ymykfka5peelkqxp@phenom.ffwll.local> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/06/17 05:14 PM, Daniel Vetter wrote: > On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote: >> On 21/06/17 04:38 PM, Daniel Vetter wrote: >>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote: >>>> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get >>>> totally obsolete. >>>> >>>> I think the gamma_store can end up invalid on error. But the way I read >>>> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should >>>> this pesky legacy fbdev stuff be any better? >>>> >>>> drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However, >>>> it saves it to the gamma_store which should already be up to date with what >>>> .gamma_get would return and is thus a nop. So, zap it. >>> >>> Removing drm_fb_helper_save_lut_atomic should be a separate patch I >>> think. >>> >>>> Signed-off-by: Peter Rosin >> >> [...] >> >>>> @@ -1167,50 +1150,6 @@ void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper, >>>> } >>>> EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked); >>>> >>>> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green, >>>> - u16 blue, u16 regno, struct fb_info *info) >>>> -{ >>>> - struct drm_fb_helper *fb_helper = info->par; >>>> - struct drm_framebuffer *fb = fb_helper->fb; >>>> - >>>> - if (info->fix.visual == FB_VISUAL_TRUECOLOR) { >>> >>> This case here seems gone, and it was also the pièce de résistance when I >>> tried tackling fbdev lut support. As far as I understand this stuff we do >>> not support FB_VISUAL_TRUECOLOR palette, and all that bitshifting here is >>> pointless. But I'm honestly not really clear. >>> >>> I think removing this case should also be a separate patch, and I'd very >>> much prefer that someone with some fbdev-clue would ack it. >> >> No need for anyone with fbdev-clue, just run fbset -i. :) Adding Bartlomiej and the linux-fbdev list, just in case I'm wrong below. >> fbcon uses a TRUECOLOR visual at depths > 8. > > Then I understand even less what exactly this code does ... Should we keep > it? I think we need it. It updates the entries of info->pseudo_palette, which is kind of a pseudocolor palette mapping 16 indices to pixel values to write to the framebuffer. If the setcolreg hook is removed, the setcmap hook needs to do this instead. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer