linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Egbert Eich <eich@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Egbert Eich <eich@suse.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: vgacon fixes to help font restauration in X11
Date: Mon, 17 Jan 2005 15:29:44 +0100	[thread overview]
Message-ID: <16875.52184.169399.632936@xf14.local> (raw)
In-Reply-To: alan@lxorguk.ukuu.org.uk wrote on Monday, 17 January 2005 at 12:23:21 +0000

Alan Cox writes:
 > On Llu, 2005-01-17 at 09:07, Egbert Eich wrote:
 > > Can you point me to these reports?
 > > I tested with a couple chipsets here and didn't find any problems.
 > 
 > I'll take a dig. The ones I've got are for 2.4 so relate to old code.
 > 
 > > We could check for the kernel version. This could be done during build
 > > time - assuming we don't ship generic binaries or during run time if we
 > > want to provide binaries that work everywhere.
 > > In reality the former would be sufficient for a lot of cases - especially
 > > for vendor supplied binaries.
 > 
 > The former would be a disaster for Fedora for example - we ship
 > 'current' kernels and having kernel upgrades require a new X11 won't
 > endear users . A runtime check on version might work I was wondering if

No, it would rather be the other way around. A new version of X would
require a certain version of the kernel - unless you plan to drop the 
feature again.
This however will not be necessary until 6.9/7 (however it will be named)
comes out.
I can implement both ways. Since the new font code lives in the OS dependent
part this should not be a problem at all.
The only disadvantage may be that I may not be able to turn off the old
font code in the generic vgaHW stuff.

 > it would be better to have an actual interface that said "do/do not
 > restore the extra bits in kernel".
 > 
 > That also avoids any suprises and regressions ?

I used to have a patch like that. But kernel people I've talked to told
me that it would be preferrable not to change the API if not necessary.

In my opinion it is not. The changes only affect cases where a new font
gets written or restored.

 > > Anyway, would my patch be acceptable for the kernel?
 > 
 > I'm not video maintainer but other than the detection question it looks
 > sensible to me.
 > 

OK, sounds promising. The changed Xserver pieces are in HEAD of the 
X.Org tree. I'll see that I make the necessary adjustments to have
a soft detection if you can give me a version number of the kernel
which will have the new features.

Egbert.


  reply	other threads:[~2005-01-17 14:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-11 14:28 vgacon fixes to help font restauration in X11 Egbert Eich
2005-01-15  0:33 ` Alan Cox
2005-01-17  9:07   ` Egbert Eich
2005-01-17 12:23     ` Alan Cox
2005-01-17 14:29       ` Egbert Eich [this message]
2005-01-17 16:30         ` Alan Cox
2005-01-18  8:31           ` Egbert Eich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16875.52184.169399.632936@xf14.local \
    --to=eich@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).