Am Sat, 15 Apr 2017 23:47:19 -0700 Kevin Oberman <rkoberman_at_gmail.com> schrieb: > On Sat, Apr 15, 2017 at 10:55 PM, O. Hartmann <ohartmann_at_walstatt.org> > wrote: > > > Am Sat, 15 Apr 2017 18:00:18 -0700 > > Conrad Meyer <cem_at_freebsd.org> schrieb: > > > > > On Sat, Apr 15, 2017 at 1:21 PM, O. Hartmann <ohartmann_at_walstatt.org> > > wrote: > > > > Am Sat, 15 Apr 2017 20:03:50 +0000 (UTC) > > > > Bruce Evans <bde_at_FreeBSD.org> schrieb: > > > > > > > >> Author: bde > > > >> Date: Sat Apr 15 20:03:50 2017 > > > >> New Revision: 316977 > > > >> URL: https://svnweb.freebsd.org/changeset/base/316977 > > > > > > > > There is a lot of development going on theses days for syscons. What's > > about vt()? > > > > vt() is considered broken for x11/nvidia-driver and vt() is considered > > a requirement > > > > when UEFI is boot scheme, isn't it? > > > > > > > > I'm just curious. > > > > > > 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 > > > > 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 > > > > 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_at_ found the job much uglier than he anticipated when he took the > Foundation commission to write it. Since then it has been widely disparaged > 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_at_gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 Hello Kevin. So, what you say is: vt(4) is a kind of unwanted child, not to say: "part time orphaned"? As far as I know, vt(4) is a requirement for UEFI/EFI booting. We do so were 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 environment for science, where a sophisticated infrastructure isn't available like graphical 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 nVidia driven systems, with the newer drivers the console is garbage (on non-vt) when using sc(4) on legacy booting boxes, with UEFI, vt(4) and nvidia produce a blank console. I've already written a message to nVidia, but with no response until now for more than half a year and the issue is present more than a year(!!!). As long as the nvidia kernel module 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 problems. 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 for this list. Thanks for your patience to read and answer. Happy Easter, Oliver Hartmann -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC