Date: Sun, 16 Apr 2017 09:07:47 +0200 From: "O. Hartmann" <ohartmann@walstatt.org> To: Kevin Oberman <rkoberman@gmail.com> Cc: "O. Hartmann" <ohartmann@walstatt.org>, Conrad Meyer <cem@freebsd.org>, FreeBSD CURRENT <freebsd-current@freebsd.org>, 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: <CAN6yY1s-_GhZ3xv_h7JHqcbXcmvxK9DRUO0hvBn8dkz_J=-7Lw@mail.gmail.com> References: <201704152003.v3FK3o3w002356@repo.freebsd.org> <20170415222136.6c58a00d@thor.intern.walstatt.dynvpn.de> <CAG6CVpWy5Y13oMra90nMkStt%2B8w85%2Byx7Qto3RCsg5-6gAY9tw@mail.gmail.com> <20170416075542.022a6902@thor.intern.walstatt.dynvpn.de> <CAN6yY1s-_GhZ3xv_h7JHqcbXcmvxK9DRUO0hvBn8dkz_J=-7Lw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <rkoberman@gmail.com> schrieb: > On Sat, Apr 15, 2017 at 10:55 PM, O. Hartmann <ohartmann@walstatt.org> > wrote: >=20 > > Am Sat, 15 Apr 2017 18:00:18 -0700 > > Conrad Meyer <cem@freebsd.org> schrieb: > > =20 > > > On Sat, Apr 15, 2017 at 1:21 PM, O. Hartmann <ohartmann@walstatt.org>= =20 > > wrote: =20 > > > > Am Sat, 15 Apr 2017 20:03:50 +0000 (UTC) > > > > Bruce Evans <bde@FreeBSD.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170416090747.5154d7a5>