From owner-svn-src-head@freebsd.org Sun Apr 16 07:07:59 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFEAFD4078F; Sun, 16 Apr 2017 07:07:59 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BCE57C1; Sun, 16 Apr 2017 07:07:58 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.169.106]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MV6PJ-1cXxTD2B1Z-00YVGe; Sun, 16 Apr 2017 09:07:54 +0200 Date: Sun, 16 Apr 2017 09:07:47 +0200 From: "O. Hartmann" To: Kevin Oberman Cc: "O. Hartmann" , Conrad Meyer , FreeBSD CURRENT , svn-src-head@freebsd.org Subject: Re: svn commit: r316977 - head/sys/dev/syscons Message-ID: <20170416090747.5154d7a5@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <201704152003.v3FK3o3w002356@repo.freebsd.org> <20170415222136.6c58a00d@thor.intern.walstatt.dynvpn.de> <20170416075542.022a6902@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/EjWsezWUoSFHAzLKiVkrOOq"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:dbkRiTqNn/7a0xGwaMsZMSWTkQRFoLxL0bQBn3PSNTu3jpnkq3T AH0DFJKhIKp8mAG1VVkFggkut9YFpcpNpspx4zjuMk9MP6VZgJbR5qt2Z/0KS1G5RbeNFj6 g42koQHCTinIAgsjs+8fZirQm9i4azyg15omVRwgTlwb6aH2mUA9hQx5Md+EuyGMtduid5f eovjO6gMWgvY9NAVtHh9Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:aZcPHcpEwbE=:PmVUA34MKbDTXIt7GuQo32 zSLpzJ9u3yunbXUh7reECcaYrMIXVAKbRG37w2+NqdT/h0zOxOA96zQypNY8caz9tKs7ZgK1L DBReb+9DyRx0th/c5raUeTJMdlLLuRAUauosVZaUd8kRXnL2lDMoq2+9Sd0ubM/PGpU2txED8 MLmq48o1uEDzHkXDu2oBxITZUeW+GIbmBE2Lu9Y5ghFT5p5A9SN27ZK0Up8PYeYgwvrUt31SD 4PNPigXZVPP386YA+6t2kTh56aFCxQEtFMReWtU3ws3PMF6WZhgtW874dhdP2TWzGTw7pGu/9 tMC85ndW3KRU3ix9ZFGtrBhEM0O2VJzm0ucPAiE0+UnJRfLc4ocRLtPxBiHBBQlyrHz42rjLs Dx1UxRtXkxihTRM/mVdDLejv4bTU77T8TOHoEsFpX8Sj7uNoGetR8P+6cJB77VYKpZunl2+6B Wq3SI9RpaSqvYcbm62JEdM4gsEg7JY/IvX6YsBmI+f3yJH9Rap6v77Q31e88BPlzOHeBBcK2F bv/it2gYRtnsx94Ac0Y+u8yzyHWDhAGh7Y56pXLNUbq2JdCWEx2H0r3fdO21Y0S8JrAwWLMiS bVMGZVFyihADhaCc6hEz2fufI6CTlUyMoxRJ5riMPt18j1sHdeUN4lIsLV4DfVNe5yhOOTdQA /bLcNw8DrwQQ132uI9uUsDIj/i6YiY5ZDcPi1fN3OtGkesUhcu9GTUfMzFfIvJbwC85IpOFyG jxPa3ONs/KAI3DxWmwooE5/wqO/IXTiqx4E/Iro2CPqN09ka64scJeWaSm4= X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 07:08:00 -0000 --Sig_/EjWsezWUoSFHAzLKiVkrOOq Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Sat, 15 Apr 2017 23:47:19 -0700 Kevin Oberman schrieb: > On Sat, Apr 15, 2017 at 10:55 PM, O. Hartmann > wrote: >=20 > > Am Sat, 15 Apr 2017 18:00:18 -0700 > > Conrad Meyer schrieb: > > =20 > > > On Sat, Apr 15, 2017 at 1:21 PM, O. Hartmann = =20 > > wrote: =20 > > > > Am Sat, 15 Apr 2017 20:03:50 +0000 (UTC) > > > > Bruce Evans schrieb: > > > > =20 > > > >> Author: bde > > > >> Date: Sat Apr 15 20:03:50 2017 > > > >> New Revision: 316977 > > > >> URL: https://svnweb.freebsd.org/changeset/base/316977 =20 > > > > > > > > There is a lot of development going on theses days for syscons. Wha= t's =20 > > about vt()? =20 > > > > vt() is considered broken for x11/nvidia-driver and vt() is conside= red =20 > > a requirement =20 > > > > when UEFI is boot scheme, isn't it? > > > > > > > > I'm just curious. =20 > > > > > > Hi O., > > > > > > Bruce uses syscons and cares enough to improve it. He likely does not > > > care about UEFI and definitely does not care about vt. I don't think > > > there's anything wrong with that. We can't force volunteers to work > > > on things they are not interested in. > > > > > > Best, > > > Conrad =20 > > > > Hello Conrad, happy easter. > > > > There is and was never intention to apply "force", it is a question as = I'm > > curious about > > what's going on with vt() - no personally bound to B. Evans or anybody > > else - I just took > > the chance to comment/ask on that subject when I saw postings. > > > > Maybe not the right place to spread some thinkings. > > > > Regards, > > > > Oliver Hartmann > > =20 >=20 > vt(4) is not a pleasant thing to look at. I am not implying that it is bad > code or badly done. I am just saying that it is pretty gnarly and is not > the sort of thing most enjoy dealing with. I got the distinct feeling that > ray@ found the job much uglier than he anticipated when he took the > Foundation commission to write it. Since then it has been widely disparag= ed > for the things that it does not do, but I am not aware that anyone has > gotten further than looking at what is needed and then running far > away.Some day someone (or some company) will get sufficiently inspired to > either re-write if or add the missing features. I have no idea when that > might happen, though. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 Hello Kevin. So, what you say is: vt(4) is a kind of unwanted child, not to say: "part t= ime orphaned"? As far as I know, vt(4) is a requirement for UEFI/EFI booting. We do so wer= e we can and so we rely on vt(4). Please correct me if I'm wrong. We also use vt(4) with pleasure for most of our servers's consoles - due to= the great improvements due to the higher resolution which makes it very easy to edit = files/issue commands/get results on the console. Especially in an experimental environm= ent for science, where a sophisticated infrastructure isn't available like graphica= l terminals and so on. Personally, I use FreeBSD even as workstation, apart from others, equipted = with the only-left working GPU vendor, nVidia, for high-performance graphics (Intel = iGPU is fine for laptops, but ... ), and here we run into a serious problem: on all nVid= ia driven systems, with the newer drivers the console is garbage (on non-vt) when usi= ng sc(4) on legacy booting boxes, with UEFI, vt(4) and nvidia produce a blank console.= =20 I've already written a message to nVidia, but with no response until now for more than h= alf a year and the issue is present more than a year(!!!). As long as the nvidia kernel mo= dule is loaded, the console is unusable and the nvidia module somehow blocks rebooting some= of our Fujitsu Celsius workstations. On a test box, I run 381.09 - the same proble= ms. By definition, vt(4) and nVidia driver has to be considered broken and this= should be reflected then in some message from the driver - but this isn't a subject f= or this list. Thanks for your patience to read and answer. Happy Easter, Oliver Hartmann --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/EjWsezWUoSFHAzLKiVkrOOq Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWPMYQwAKCRDS528fyFhY lLGkAfwJS9bfXMUsXbph0PbOcCOdEcMOuPQdtrZ0AycE34GXgHywycHmbIjD22G4 9E8dkVsOZ3znS5ENnFu4MA5NKO2HAf449rp2rVf3ANte2cTCbSo25+luKbQjFsDT kQdp5MdozsrxJEUDS8HdEWSS9TtHGh7oZFyBhILTK7QNjHFpByQ1 =GcB2 -----END PGP SIGNATURE----- --Sig_/EjWsezWUoSFHAzLKiVkrOOq--