From nobody Fri Nov 26 16:16:17 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2CAB618C4C14 for ; Fri, 26 Nov 2021 16:16:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J10H66Lx7z3trQ for ; Fri, 26 Nov 2021 16:16:18 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1637943377; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8HB6dEr6CK0xq7n6Bvijt/5ArTgQzf4oEtatPgz+N0g=; b=c2DQ5Ry99uRN5LRT2TTaLoq7OSI7FPu3FK+GXDmb8iIhkklWhVJ6ErW0VY9TfY3gPOlxuo VDGHyodLx7fk5jOYbMSoh0Q88iBr/nSEPSm/eRKvQh/N6LyjhHit/s6mRNKLY3l4WHdfGP qQHzwGIbQJtrodjdoHJU4rf9iM+K99k= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id c77801a9 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 26 Nov 2021 16:16:17 +0000 (UTC) Date: Fri, 26 Nov 2021 17:16:17 +0100 From: Emmanuel Vadot To: Stefan Blachmann Cc: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20211126171617.f57c65e9c4dbdb0d1a2863c0@bidouilliste.com> In-Reply-To: References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J10H66Lx7z3trQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 26 Nov 2021 16:45:17 +0100 Stefan Blachmann wrote: > Main technical reasons why I consider sc(4) essential: > > - vt/vesa.ko break suspend/resume on nvidia cards. To make > suspend/resume work on computers with nvidia, it is necessary to build > a kernel *without* vt/vesa modules. See > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253733 I'm not sure I understand your report, does the system suspend/resume fine if you use vt or not ? To me it seems that the problem is when you have vt(4) in the kernel but uses sc(4). > - vt is so horridly buggy that it is no fun to use it at all if one is > accustomed to well-working, bugfree sc(4). Just one example: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211922 Oh yes, one scroll bug that I even can't reproduce locally clearly makes vt(4) 'horridly buggy'. > > The hate and disregard against sc(4) and against nvidia and the > arrogance that can be observed from some FreeBSD core guys amazes me > again and again. > I often wonder why Nvidia has not already dropped FreeBSD support due > to such attitudes. > > > On 11/26/21, Emmanuel Vadot wrote: > > > > Hello all, > > > > I'm currently re-implementing the framebuffer code in linuxkpi for > > drm-kmod and this made me look at sc(4), vt(4) and friends. > > > > So I looked at what sc could do and vt couldn't and vice-versa. > > > > What sc(4) can't do : > > > > - Work with EFI firmware. > > - Support UTF-8 > > - Maybe other things but everything here is EFI-based so let me know. > > > > What vt(4) can't do : > > > > - You can't get the modes or adapter info with vidcontrol. > > vidcontrol -i mode is really made for anything vesa based as it > > iterates on all the modes and display them if present. > > In the modern world (EFI), we don't have that, EFI GOP doesn't > > support changing resolution after ExitBootService was called so there > > is only one "mode". I could possibly hack some patch so vidcontrol -i > > mode/adapter would work and display the current framebuffer info if > > people wants (but I honestly doubt that vidcontrol is useful at all in > > an EFI world). > > - "Blanking" screen doesn't do what you think it does. For some reason > > in vt(4) we just write black colors on the screen and ignore the blank > > mode passed in the ioctl. > > Now again, blanking/dpms/blah isn't possible with efi_fb but it make > > sense to fix vt(4) and drm-kmod so it calls the drm module blanking > > function, I'll work on that next week. > > - There is no screensaver, again see notes above for dpms but do > > people still use sc(4) just for the screensaver ?? > > - Maybe other things, please let me know. > > > > For libvgl it probably made sense back in the 90s but does it now ?? > > > > Based on my small list I don't see any good reason to keep sc(4) but > > maybe I've missed something bigger so please let me know. > > > > P.S.: I'm really not interested by people saying stuff like > > "I've always used sc(4), it works for me don't touch it" > > without some technical argument. > > > > Cheers, > > > > -- > > Emmanuel Vadot > > > > -- Emmanuel Vadot