From owner-freebsd-current@freebsd.org Tue Jun 21 04:10:12 2016 Return-Path: Delivered-To: freebsd-current@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 F2548A7A5AC for ; Tue, 21 Jun 2016 04:10:12 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B99EB1B09; Tue, 21 Jun 2016 04:10:12 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-it0-x235.google.com with SMTP id h190so5499747ith.1; Mon, 20 Jun 2016 21:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ukf7gnlXaYkti8W/I1mXAfzF+GdNonqLUmPRfk9bF4k=; b=zQwSyK2hxXu5u910oCoq9oupI56j9SrWXSHzN4EZd89E1B3ei1aN9KloM2CNP0ggXU Rkj2GqbR0JvMR3XdIo5+z+Wd8VfiCybuQBUlf+B3iw22DibWYObHdMaYQXGWAzOZL5Vh G6bJcdeAalA0SKc9Hex5wdemcO9+1aEWyd0jn2KqmdnQQ/gcG/FNMLHouv4GVdazEFhM ocICLfhz4BHhQwBflERbUGKH5bpW00JaeJ8Atit/fPOkCVKnjavpmLggtYLwjzrG9b+P S0TZYIZPOEb9CtWydfqPPvPAa/5VRAc2DTswbOGfY/k8mlUP33oRnk6iVvNi+EqeemHW OrFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ukf7gnlXaYkti8W/I1mXAfzF+GdNonqLUmPRfk9bF4k=; b=QvQypPv20l0q3OkbzbK3cqD1FhKtH9eYzAyWn+XqZhnVqALWgq8uiC5KD/KquKB12N wqTshLcjk237eZA/krcYOpVT4S93QPdXtXkQoRbcVvU1H83jDkxzGOwdEh4giPZIq3S/ PIP+MtznhTuUyIOV5Dfg+0F60kRTsb5sdQ2NiRRbQAkGJHdwGohBw4nJeIfJIf07v+Yy e8Ka49vv44BCoytzXHBaqFzZeS8P/v9MxClGc0+lGRPJq3uflmxhf75I33Nkc6s4hNtW V/4irtW/9Noab83Jv681ELFQ7nDJGLZ49VhYqG7Bdc+k/hmqeq6efSnZk5kgChufNqbI 2xwA== X-Gm-Message-State: ALyK8tLB6CShpm/C4xVINsHjaN6k65tB+NwkwGxICsAQdK1GUyjjP8c6ASvW5cWPzmJlvZ//DrRW+wyk1CAYag== X-Received: by 10.36.64.73 with SMTP id n70mr1936126ita.53.1466482212123; Mon, 20 Jun 2016 21:10:12 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.79.102.5 with HTTP; Mon, 20 Jun 2016 21:10:11 -0700 (PDT) In-Reply-To: <576891F8.1010200@gmail.com> References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com> <31205295.d0H0JTrSWj@ralph.baldwin.cx> <576891F8.1010200@gmail.com> From: Kevin Oberman Date: Mon, 20 Jun 2016 21:10:11 -0700 X-Google-Sender-Auth: 0IvXrsytdUkuyrbPDtB7Q9gjngA Message-ID: Subject: Re: console in 11.0-ALPHA4 To: Ernie Luzar Cc: John Baldwin , Ed Maste , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 04:10:13 -0000 On Mon, Jun 20, 2016 at 6:01 PM, Ernie Luzar wrote: > John Baldwin wrote: > >> On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote: >> >>> Ed Maste wrote: >>> >>>> On 20 June 2016 at 14:29, Ernie Luzar wrote: >>>> >>>>> I found the cause of this boot time message >>>>> "vicontrol: setting cursor type: Inappropriate ioctl for device" >>>>> >>>>> In my rc.conf I had this statement >>>>> vidcontrol -c blink -h 250 >>>>> From testing it seems that vt does not handle the "blink" option for >>>>> causing >>>>> the cursor to blink. Is there a vt option to enable cursor blinking >>>>> >>>> I've submitted two PRs for the issues you reported here: >>>> Bug 210413 - vidcontrol -c does not work >>>> with vt(4) >>>> Bug 210415 - vidcontrol -h does not work with vt(4) >>>> (edit) >>>> >>>> There is currently no option to enable cursor blinking. >>>> >>> >>> Further testing shows that: >>> >>> 1. The rc.conf option screen saver "saver= " and the "blanktime= " >>> options work in vt for both text and graph modes. >>> >>> 2. The cursor copy/paste does not work in vt text mode. It only works in >>> vt graph mode. vt needs to be fixed so copy/paste function also works in >>> text mode. >>> >>> 3. Boot time splash screen does not work in vt at all no matter which >>> mode is enabled. Using this in loader.conf >>> splash_bmp_load="YES" >>> bitmap_name="/boot/splash.bmp" >>> bitload_load="YES" >>> >>> This works in 10.x. The splash screen function can not be allowed to be >>> removed from the base system just because vt can not handle it. This also >>> means any vt changes need to updated in the handbook section on splash >>> screen. >>> >>> In conclusion, vt is not ready to replace the sc console driver yet. vt >>> needs to be fixed before becoming the default in 11.0. Using vt as the >>> default console driver effects every user. It completely changes the >>> FreeBSD experience. It's detrimental to the public relations and the >>> professional image of FreeBSD to publish the 11.0-RELEASE using vt in its >>> current condition. If time doesn't permit to get these vt things fixed >>> before publishing 11.0 then vt should not become the default console driver. >>> >> >> OTOH, if you use EFI, then you can't use sc(4). You get no working >> console >> with EFI (which is becoming more popular) if you use sc(4). You also do >> not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable >> console if you use sc(4). You also do not have a working console after >> loading the KMS drivers (either by starting X or via explicit kldload) >> when >> using sc(4). This affects just about every modern Intel system using an >> Intel GPU (so more widespread than EFI even). >> >> There are trade offs in both directions. Neither console is a subset of >> the >> other. However, sc(4) is not really expendable to support the things it >> is >> missing. vt(4) is actively worked on, and patches for the features it >> lacks >> that you need are certainly welcomed. >> >> > This sounds like a integration design error. From your description of the > hardware that vt is designed for and sc is designed for indicates the need > for some code to be added to the boot process that inspects the hardware > and decides whether vt or sc is to be launched. Or maybe bsdinstall should > inspect the hardware and give the installer the option to select what > console is best for his hardware. Just forcing this version of vt that > lacks long time functions as the default console driver is not the > professional way to handle such conflicts. > > I am at a lost to understand how any development administrator would > approve making vt the default console driver in light of the standard > functions missing from it. And furthermore what kind of vt testing was done > that these problems were missed. Any one of these problems is enough cause > to reverse the decision to make vt the default console driver for 11.0. > This would give time for these problems to be address and correctly tested > and when ready then be paced in some other 11.x release. There is really no choice. vt(4) will work as a basic console on all platforms. sc(4) works on old hardware, but not on an increasingly large portion of "modern" hardware. Since being able to boot on most hardware is critical as well as supporting non-CP437 languages. It' pretty much a no-brainer. And, since switching back to SC(4) is trivial (add "kern.vty=sc" to /boot/loader.conf), I believe any other option would be totally unacceptable. It is important that the release notes for 11 clarify these changes and make it clear how to switch. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683