ht thing even if it takes longer. Really appreciate you
> taking the time to respond, thanks!
>
> Anindya
>
> From: Adrian Chadd [adrian.ch...@gmail.com]
> Sent: January 20, 2017 3:11 PM
> To: Anindya Mukherjee
> Cc: freebsd-current
t: January 20, 2017 3:11 PM
To: Anindya Mukherjee
Cc: freebsd-current@freebsd.org
Subject: Re: vt(4) chops off the leftmost three columns
hiya,
Mechanically it doesn't look /that/ hard:
* vesa.ko pulls in the vesa.c bits and the syscons vesa control bits.
Ideally we'd have them as two
Thanks! I needed a breakdown like this. I'll need to study the code a bit more.
Anindya
From: Adrian Chadd [adrian.ch...@gmail.com]
Sent: January 20, 2017 3:11 PM
To: Anindya Mukherjee
Cc: freebsd-current@freebsd.org
Subject: Re: vt(4) chops of
hiya,
Mechanically it doesn't look /that/ hard:
* vesa.ko pulls in the vesa.c bits and the syscons vesa control bits.
Ideally we'd have them as two separate modules, so you could load
"vesa" without needing the syscons bits.
* Maybe then write a vt 'fb' interface to talk to the old-school
framebu
Hi Adrian,
I was looking at the source for the vt driver. Wondering how much work it is to
add VESA support to the VGA backend? As you say ATM it's hardcoded to use
640x480. Pardon my ignorance, but can we reuse any VESA code from syscons?
Also, how dependent is splash/screensaver support on th
heh.
As always, patches gratefully accepted. :)
-adrian
On 14 January 2017 at 21:07, Ernie Luzar wrote:
>
> You can add these things to the vt to-do list
>
> Change the default font to look like sc.
> Add copy/paste function like sc has.
> Add splash screen support like sc has.
>
>
>
> Adria
You can add these things to the vt to-do list
Change the default font to look like sc.
Add copy/paste function like sc has.
Add splash screen support like sc has.
Adrian Chadd wrote:
hi,
no, the vt_vga backend doesn't yet do VESA.
I keep meaning to sit down and fix this, but life and wifi g
hi,
no, the vt_vga backend doesn't yet do VESA.
I keep meaning to sit down and fix this, but life and wifi gets in the way.
-adrian
On 14 January 2017 at 16:27, Kevin Oberman wrote:
> On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd
> wrote:
>>
>> It depends(tm). I think the VT code just does
On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd
wrote:
> It depends(tm). I think the VT code just does "640x480x4bpp" and lets
> the BIOS sort it out. A lot of things don't cope well with 640x480
> these days - they try autodetecting picture edges, but a black border
> makes that very difficult.
>
It depends(tm). I think the VT code just does "640x480x4bpp" and lets
the BIOS sort it out. A lot of things don't cope well with 640x480
these days - they try autodetecting picture edges, but a black border
makes that very difficult.
-adrian
On 14 January 2017 at 08:57, Matthias Andree wrote:
On Sat, Jan 14, 2017 at 4:43 AM, David Chisnall wrote:
> On 13 Jan 2017, at 01:00, Ernie Luzar wrote:
>>
>> VT should have had better testing before becoming the default in 11.0.
>
> The choice was VT or no acceleration in X11, because all of the new DRI
> drivers depend on KMS, which requires V
Am 14.01.2017 um 00:11 schrieb Alan Somers:
> I take it back. The first three columns _are_ rendered, but they
> don't show up on some monitiors. It's as if those monitors require a
> minimum amount of overscan on the left side of the screen, and vt(4)
> doesn't provide enough. Can that be tuned
On 13 Jan 2017, at 01:00, Ernie Luzar wrote:
>
> VT should have had better testing before becoming the default in 11.0.
The choice was VT or no acceleration in X11, because all of the new DRI drivers
depend on KMS, which requires VT. We only got VT in a useable state (and
therefore useable ac
On Thu, Jan 12, 2017 at 7:31 PM, Ngie Cooper (yaneurabeya)
wrote:
>
>> On Jan 12, 2017, at 18:13, Ed Maste wrote:
>>
>> On 12 January 2017 at 18:50, Alan Somers wrote:
>>> I've seen three separate machines where FreeBSD11's vt(4) driver chops
>>> off the leftmost three columns of the screen. Re
> On Jan 12, 2017, at 18:13, Ed Maste wrote:
>
> On 12 January 2017 at 18:50, Alan Somers wrote:
>> I've seen three separate machines where FreeBSD11's vt(4) driver chops
>> off the leftmost three columns of the screen. Rendering simply starts
>> at the beginning of the fourth column. In all
On 12 January 2017 at 18:50, Alan Somers wrote:
> I've seen three separate machines where FreeBSD11's vt(4) driver chops
> off the leftmost three columns of the screen. Rendering simply starts
> at the beginning of the fourth column. In all cases, setting
> "kern.vty=sc" corrects the problem.
O
Alan Somers wrote:
I've seen three separate machines where FreeBSD11's vt(4) driver chops
off the leftmost three columns of the screen. Rendering simply starts
at the beginning of the fourth column. In all cases, setting
"kern.vty=sc" corrects the problem. The three different systems are:
1)
17 matches
Mail list logo