On Mon, Nov 09, 2009 at 06:18:41PM +0100, Robert Millan wrote:
> We don't have GRUB_ASSUME_LINUX_HAS_FB_SUPPORT anymore. Does this
> patch still make sense? (or some part of it? I suspect
> GRUB_LINUX_VID_MODE_CURRENT is still useful).
Given the kernel issues with it, I've withdrawn this patch
On Mon, Aug 10, 2009 at 12:01:02PM +0100, Colin Watson wrote:
> If the user set "keep" in gfxpayload, as I understand it, that indicates
> that they want the graphical mode set by GRUB to persist through to the
> kernel. In order for this to actually work with Linux, we need to set up
> the vid_mod
On Mon, Aug 24, 2009 at 6:38 PM, Colin Watson wrote:
> On Mon, Aug 24, 2009 at 04:26:09PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> On Mon, Aug 10, 2009 at 6:41 PM, Colin Watson wrote:
>> > On Mon, Aug 10, 2009 at 06:27:04PM +0200, Vladimir 'phcoder' Serbinenko
>> > wrote:
>> >> Framebuffer c
On Mon, Aug 24, 2009 at 04:26:09PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Mon, Aug 10, 2009 at 6:41 PM, Colin Watson wrote:
> > On Mon, Aug 10, 2009 at 06:27:04PM +0200, Vladimir 'phcoder' Serbinenko
> > wrote:
> >> Framebuffer console works just fine with no KMS if video mode is
> >> al
On Mon, Aug 10, 2009 at 6:41 PM, Colin Watson wrote:
> On Mon, Aug 10, 2009 at 06:27:04PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> Framebuffer console works just fine with no KMS if video mode is
>> already set and video parameters passed. At least technically.
>
> Feel free to show me what I
On Mon, Aug 10, 2009 at 05:18:42PM +0100, Colin Watson wrote:
>
> (It's not actually quite true that vid_mode isn't used *at all* with the
> 32-bit boot protocol; it's still saved for use with ACPI sleep.)
In this case, I suppose we should set it. Currently we don't, because I was
under the impr
On Mon, Aug 10, 2009 at 10:16 PM, Colin Watson wrote:
> On Mon, Aug 10, 2009 at 10:01:06PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> If these numbers are still needed it needs to be uniform between
>> gfxpayload=1024x768 or gfxpayload=keep + gfxmode=1024x768. Derive the
>> number from video mo
On Mon, Aug 10, 2009 at 10:01:06PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> If these numbers are still needed it needs to be uniform between
> gfxpayload=1024x768 or gfxpayload=keep + gfxmode=1024x768. Derive the
> number from video mode information if you really need it
I couldn't find terri
>
> Hmm. You seem to be right, on investigation (I'd missed the fact that
> the 32-bit boot protocol skips a whole bunch of initialisation code),
> but in that case I'm thoroughly confused about why setting it made any
> difference at all in my tests. Back to the drawing board, I guess.
>
> (It's n
On Mon, Aug 10, 2009 at 06:27:04PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> Framebuffer console works just fine with no KMS if video mode is
> already set and video parameters passed. At least technically.
Feel free to show me what I'm doing wrong, but it demonstrably does not
work right now
>
> I don't think it's relevant to Matthew's argument what GRUB happens to
> use to implement the graphical mode. The only way that Linux can write
> text to the screen in graphical mode is if it has a framebuffer driver
> to do so, which needs some kind of substrate (be that VESA or something
> sm
On Mon, Aug 10, 2009 at 05:27:25PM +0200, Robert Millan wrote:
> On Mon, Aug 10, 2009 at 02:05:15PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > What is the linux behaviour with 0x0F04? Does it just keep the mode?
> > What if the same mode is passed as a value? Does linux redoes the
> > modesett
On Mon, Aug 10, 2009 at 05:15:41PM +0200, Robert Millan wrote:
> On Mon, Aug 10, 2009 at 12:58:35PM +0100, Colin Watson wrote:
> > It also seems that doing this right is tricky on the kernel side (see
> > https://lists.ubuntu.com/archives/kernel-team/2009-August/006773.html
> > and thread), so I pr
On Mon, Aug 10, 2009 at 02:05:15PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> What is the linux behaviour with 0x0F04? Does it just keep the mode?
> What if the same mode is passed as a value? Does linux redoes the
> modesetting? If 0x0F04 works ok I would prefer to always pass it when
> kernel
On Mon, Aug 10, 2009 at 12:58:35PM +0100, Colin Watson wrote:
> On Mon, Aug 10, 2009 at 01:49:40PM +0200, Robert Millan wrote:
> > On Mon, Aug 10, 2009 at 12:01:02PM +0100, Colin Watson wrote:
> > > If the user set "keep" in gfxpayload, as I understand it, that indicates
> > > that they want the gr
On Mon, Aug 10, 2009 at 02:38:42PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> Colin Watson wrote:
> > Yes, it completely skips modesetting.
> >
> >> What if the same mode is passed as a value? Does linux redoes the
> >> modesetting?
> >
> > Yes, which permits it to display text since now it's se
> Yes, it completely skips modesetting.
>
>> What if the same mode is passed as a value? Does linux redoes the
>> modesetting?
>
> Yes, which permits it to display text since now it's set up a linear
> framebuffer.
Why can't linux use linear framebuffer for its framebuffer console?
>
>> If 0x0F04 w
On Mon, Aug 10, 2009 at 02:05:15PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> Colin Watson wrote:
> > This doesn't quite work perfectly yet. It's better than before - I've
> > tested this, and if everything works properly then the result is a
> > smooth zero-flicker transition, which is wonderfu
> I think I'll remove GRUB_ASSUME_LINUX_HAS_FB_SUPPORT. It seems that nobody
> is going to use it, so all it does is add complexity. This will also make
> your patch simpler.
>
> Is there any objection to that?
I'm ok with that. Generally I think that whenever we have the same
configuration avail
> This doesn't quite work perfectly yet. It's better than before - I've
> tested this, and if everything works properly then the result is a
> smooth zero-flicker transition, which is wonderful. However, if
> something goes wrong before the kernel starts a framebuffer then it has
> no way to displa
On Mon, Aug 10, 2009 at 01:49:40PM +0200, Robert Millan wrote:
> On Mon, Aug 10, 2009 at 12:01:02PM +0100, Colin Watson wrote:
> > If the user set "keep" in gfxpayload, as I understand it, that indicates
> > that they want the graphical mode set by GRUB to persist through to the
> > kernel. In orde
On Mon, Aug 10, 2009 at 12:01:02PM +0100, Colin Watson wrote:
> If the user set "keep" in gfxpayload, as I understand it, that indicates
> that they want the graphical mode set by GRUB to persist through to the
> kernel. In order for this to actually work with Linux, we need to set up
> the vid_mod
If the user set "keep" in gfxpayload, as I understand it, that indicates
that they want the graphical mode set by GRUB to persist through to the
kernel. In order for this to actually work with Linux, we need to set up
the vid_mode boot parameter to indicate that it should keep the current
video mod
23 matches
Mail list logo
