From owner-freebsd-x11@freebsd.org Mon Apr 13 10:21:09 2020 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 840AE2B9879 for ; Mon, 13 Apr 2020 10:21:09 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4914QY31xzz4Pjp for ; Mon, 13 Apr 2020 10:21:09 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 65DDF2B9878; Mon, 13 Apr 2020 10:21:09 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 65A222B9877 for ; Mon, 13 Apr 2020 10:21:09 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (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 4914QY1QDsz4Pjl; Mon, 13 Apr 2020 10:21:09 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 4914QT4Rd8z3m7X; Mon, 13 Apr 2020 10:21:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id WlnSL2SpPX0N; Mon, 13 Apr 2020 10:21:05 +0000 (UTC) Received: from garnet.daemonic.se (unknown [IPv6:2001:470:dca9:201:442b:819c:37fd:3e24]) by mail.daemonic.se (Postfix) with ESMTPSA id 4914QS5xTbz3lbm; Mon, 13 Apr 2020 10:21:04 +0000 (UTC) Subject: Re: Ars Technica article To: Alexey Dokuchaev , Warner Losh Cc: FreeBSD X11 References: <4e3bf6be-aecf-7c62-df98-1cc4b01b8db9@gmail.com> <43f83193-e495-2bf2-f85d-91aa0b36c1a0@gmail.com> <0e205fe8-fbc6-5d91-99b0-1bd4870b8a5d@gmail.com> <536A0D50-4119-4C28-9202-28622152B203@freebsd.org> <20200413052406.GA90880@FreeBSD.org> <20200413075034.GA46382@FreeBSD.org> From: Niclas Zeising Message-ID: <2977303f-d8a3-1071-0af5-a3f5699d0ea8@freebsd.org> Date: Mon, 13 Apr 2020 12:21:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200413075034.GA46382@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4914QY1QDsz4Pjl X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 10:21:09 -0000 On 2020-04-13 09:50, Alexey Dokuchaev wrote: > On Mon, Apr 13, 2020 at 01:11:30AM -0600, Warner Losh wrote: >> ... >> To be blunt: drm-legacy-kmod's days are numbered. It's irrelevant that it's >> the only one that "works." It's a distraction to keeping drm-kmod working >> on newer, more relevant hardware. It's unfortunate that some older hardware >> has stopped working with the newer code, but much of that is due to >> upstream pressures. > > Mind that you're talking about hardware just several years old; it's just > as relevant for its users who bought their laptop like myself ~four years > ago and now you're telling them (us) that you intend to remove the only > working DRM port. This is certainly not the way to attract more FreeBSD > desktop users; in fact, you'll likely get exactly the opposite. drm-legacy-kmod's days have been numbered for far longer than when the drm-legacy-kmod port was created. It's days was numbered even when it was part of the FreeBSD base system, it never saw any updates, and the hardware support was lacking. All that ever happened was updates to keep it compiling and hopefully running. The new lkpi based drm drivers (drm-kmod) were created to move driver support forward, so that we could get support for newer hardware. Doing it this way also meant that we have a chance to pull in updates and keep on supporting newer hardware. While there are some warts, and some cases, especially on non-amd64 hardware, where drm-legacy-kmod might work better, the goal has always been to remove it completely. > >> My reading of that PR is why xf86-video-ati-legacy was created. > > Not really: hardware cursor got broken between versions 18->19, while > legacy port tracks 7.9.0. I guess it should not be too hard to diff the > drivers' source code and try to figure out what had changed, I'd look > into this. xf86-video-ati-legacy was created when we update dxf86-video-ati to a newer version, explicitly in order to cater for drm-legacy-kmod users. We needed to update xf86-video-ati to get support in X for newer hardware, and when we got reports about there being issues with the updated video-ati, we created the -legacy version as a stop-gap measure. Now we have come to a point where we can't support that version, since it does not work with xserver 1.20. I spent some time to try to create a version that could work, but as has been pointed out by you and others, I didn't succeed. Unfortunately, I don't have the time or hardware to dig deeper into this, so if you need this, then you have to work together with Andrea Venturoli to see if you can get it working. The cursor issue was found when we updated from xf86-video-ati 18.0 to 19.0. There is a workaround, which is to use the sw cursor. I do not know if using the modesetting xorg driver works, but that could also be a solution. > >> I know you're looking for someone to blame. That person isn't Niclas. > > Oh, I'm not blaming him at all. And more to it, while Andrea Venturoli > is currently helps to debug xf86-video-ati-legacy issues, I'm not that > concerned about that driver, but rather that all other DRM ports except > legacy locking up my laptop upon "kldload radeonkms". This isn't right; > it should be debugged and fixed, and only then drm-legacy-kmod port can > be removed. Thank you for volunteering to help debug and fix why radeonkms locks up your laptop. Regards -- Niclas Zeising FreeBSD Graphics Team