From nobody Fri Nov 26 15:45: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 4219A18B3A90 for ; Fri, 26 Nov 2021 15:45:19 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0zbM1Btwz3Ny7 for ; Fri, 26 Nov 2021 15:45:19 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x134.google.com with SMTP id b1so25153328lfs.13 for ; Fri, 26 Nov 2021 07:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f6rXc/8+Gs73hfoGgM7ZWKbPxREK4rA1OTLpDpQRNks=; b=dU2fr1agRAiLEVmFJpTDyyn65VFXrvcas64dtHFtRZam/NPFC/WpOjGZRDpOD5RWUx w/EZgI/nVZzO5HXet+P7ILGAaLLSQTy54G3SDZE4WOQLTtWgxM4ZbO8DT0cY5+qV002e FH3wB5bIPyIiCe4ye8nkRwhW0SVT9giKwS93bHHybndNOnp4BLxQiP6gkTKtjdh7q03r mUhzZkx0Q/Qg2VGO7Ws1WTFxDvP/gjRsjoN4FqaLY+z4GqoyYTtURCyYDuctfRKuEy+n cpPn1wasb1KhMr10cpIYiXaamwVjNaOSV1Zx0l1oOvLkQP77+vrJXoA4MqqsvPm+lAcJ b/EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f6rXc/8+Gs73hfoGgM7ZWKbPxREK4rA1OTLpDpQRNks=; b=tMxykCAMOZC02X/r6Lbx1brEzgEhKvePjMBKGFh1+fVrsmCllaq9dNGkB8bLA0IR3n YaG8vpSY+erUYmtPe0fNOUMKADQTgpVRn77rwh+82Q7RUcQ7fGxD5cq7D6LEC2V72EML cJIw9Aw4tatJwBHlXfI7xfQ/J1K/gKOAzQ7RlmcEfxhBV0C/RuoWKXp2EN1cvvrX3Cth fdp4Azq2X0cFYz/pKTO1ME9HNdiscFIWKjxNyRHbW77JALBQhVzbWH5eQpzcIPZ5CviH qroUKCSblaYZ+3SP9CIEYQMZ70DI6agGPUt1qPefEz/Twgu9vF8FLWsjiDInlbqy+Gp4 uOcA== X-Gm-Message-State: AOAM533elfsXLoIPkY6cjj22jWm3GCT1x/Rv3OZQvh3CJ675i58KCcqK M6GUaJLLDbjsfg9nTswNxuyI8jjfk6+27VGRih5JjHE3 X-Google-Smtp-Source: ABdhPJzazX+Jawme5vqI2m++irHmWn0dSG2dzLBEfOlDFynrAh5pk+WdANJR5gPDr3Lis/MspcmDXLym77RKKs7hseA= X-Received: by 2002:a05:6512:e89:: with SMTP id bi9mr30839650lfb.465.1637941517933; Fri, 26 Nov 2021 07:45:17 -0800 (PST) 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 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Fri, 26 Nov 2021 07:45:17 -0800 (PST) In-Reply-To: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> From: Stefan Blachmann Date: Fri, 26 Nov 2021 16:45:17 +0100 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Emmanuel Vadot Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J0zbM1Btwz3Ny7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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 - 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 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 > >