Re: [PATCH v3 30/32] drm/via: Add Kconfig

From: Thomas Zimmermann <tzimmermann@suse.de>
To: Kevin Brace <kevinbrace@gmx.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 30/32] drm/via: Add Kconfig
Date: Mon, 1 Aug 2022 12:36:55 +0200	[thread overview]
Message-ID: <adae488f-9a26-c526-7c3a-5cad2c7bec07@suse.de> (raw)
In-Reply-To: <trinity-e13df8a2-fa37-4234-8787-8e57ce0d0881-1659232178771@3c-app-mailcom-bs13>

[-- Attachment #1.1: Type: text/plain, Size: 3059 bytes --]

Hi

Am 31.07.22 um 03:49 schrieb Kevin Brace:
> Hi Thomas,
> 
> In general, I am okay with the idea of keeping DRI1 based VIA DRM for now.
> Personally, I am not that interested in keeping it, but I am not against keeping it, either.

Yeah, I see your point.  No one really wants to keep the DRI1 code, but 
there might be users out there, who still rely on it.  They usually only 
show up when things break.  It's really hard to remove anything once 
it's in the kernel.

Best regards
Thomas

> Coming up with a scheme to keep the DRI1 based VIA DRM is sort of beyond my skill level,  so I am glad you and Sam came up with a scheme to keep it.
> I think we will reuse this scheme when I finally have the time to get around adding KMS support to other similar legacy DRI1 based DRM modules.
> 
> Regards,
> 
> Kevin Brace
> Brace Computer Laboratory blog
> https://bracecomputerlab.com
> 
> 
>> Sent: Tuesday, July 26, 2022 at 12:28 AM
>> From: "Thomas Zimmermann" <tzimmermann@suse.de>
>> To: "Kevin Brace" <kevinbrace@gmx.com>, dri-devel@lists.freedesktop.org
>> Cc: "Kevin Brace" <kevinbrace@bracecomputerlab.com>
>> Subject: Re: [PATCH v3 30/32] drm/via: Add Kconfig
>>
>> Hi
>>
>> Am 26.07.22 um 01:53 schrieb Kevin Brace:
>>> From: Kevin Brace <kevinbrace@bracecomputerlab.com>
>>>
>>> Signed-off-by: Kevin Brace <kevinbrace@bracecomputerlab.com>
>>> ---
>>>    drivers/gpu/drm/via/Kconfig | 9 +++++++++
>>>    1 file changed, 9 insertions(+)
>>>    create mode 100644 drivers/gpu/drm/via/Kconfig
>>>
>>> diff --git a/drivers/gpu/drm/via/Kconfig b/drivers/gpu/drm/via/Kconfig
>>> new file mode 100644
>>> index 000000000000..7c4656a1d473
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/via/Kconfig
>>> @@ -0,0 +1,9 @@
>>> +config DRM_OPENCHROME
>>
>> I would keep the driver option named DRM_VIA, as it has been so far. To
>> build the existing DRI1 driver, rather introduce a new config symbol
>> that enables it. The rule looks something like this:
>>
>>     config DRM_VIA_DRI1
>>     boolean "DRI1 support"
>>       depends on DRM_VIA && DRM_LEGACY
>>       help
>>         Build for DRI1-based userspace drivers.
>>
>> It will show up as an option if the user selects both DRM_VIA and
>> DRM_LEGACY.
>>
>> Best regards
>> Thomas
>>
>>
>>> +	tristate "OpenChrome (VIA Technologies Chrome)"
>>> +	depends on DRM && PCI && X86
>>> +	select DRM_KMS_HELPER
>>> +	select DRM_TTM
>>> +	help
>>> +	  Choose this option if you have VIA Technologies UniChrome or
>>> +	  Chrome9 integrated graphics. If M is selected the module will
>>> +	  be called via.
>>> --
>>> 2.35.1
>>>
>>
>> -- 
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>> (HRB 36809, AG Nürnberg)
>> Geschäftsführer: Ivo Totev
>>

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]