Kendall Bennett <[EMAIL PROTECTED]> wrote:
> Laptops are a little different as they will make calls from the Video
> BIOS into the system BIOS, so you need to make sure that the system BIOS
> is also available in the execution environment.
Any video BIOS (especially EGA) may call system BIOS func
Li-Ta Lo schrieb:
> On Mon, 2005-02-07 at 09:01, Pavel Machek wrote:
>
3 - it's always there and can be executed at *any* time: booting,
returning from suspend, etc. Also it would allow the VESA framebuffer
driver to change graphics mode at any time (for instance).
>>>
>>>OK, and what
Jon Smirl schrieb:
> On Thu, 10 Feb 2005 21:06:36 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
>
>>On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
>>
>>
>>>So perhaps this problem is something similar?
>
>
> What type of computer has the problem? Who makes it's video chips?
Samsu
On Thu, 10 Feb 2005, Bill Davidsen wrote:
Some systems (intel notably) appear to expect you to use the bios
save/restore video state not re-POST.
Isn't that what it's there for? In any context other than save/restore I
wouldn't think using the BIOS was a good approach. But this is a special
case,
On Thu, 2005-02-10 at 16:28 -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 21:06:36 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
> >
> > > So perhaps this problem is something similar?
>
> What type of computer has the problem? Who
On Thu, 10 Feb 2005 21:06:36 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
>
> > So perhaps this problem is something similar?
What type of computer has the problem? Who makes it's video chips?
--
Jon Smirl
[EMAIL PROTECTED]
-
To u
Matthew Garrett said the following on 2/10/2005 1:06 PM:
On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
So perhaps this problem is something similar?
I don't think so - if I dd out of ROM, I get something that looks like a
video BIOS (and, indeed, I can make VBE calls to and from it).
On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
> So perhaps this problem is something similar?
I don't think so - if I dd out of ROM, I get something that looks like a
video BIOS (and, indeed, I can make VBE calls to and from it). The
problem is jumping to c000:0003 and executing - thi
Hi Guys,
I have missed all the original emails in this thread. I was trying to
re-subscribe to the lkml a few days ago (I just switched over to
Thunderbird) but I haven't been getting any traffic. So I will try again.
The one thing I can say is that having worked extensively with ATI
cards, the
I added Kendall from Scitech to the CC list. He is the expert on
getting VBIOS's to post. Maybe he can help.
On Thu, 10 Feb 2005 20:29:47 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote:
> > On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett
On Thu, Feb 10, 2005 at 03:17:47PM -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > It also explicitly states that Windows 2000 and XP don't support this,
> > which leads me to suspect that vendors no longer expect POSTing to be
> > possib
On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > It also explicitly states that Windows 2000 and XP don't support this,
> > which leads me to suspect that vendors no longer expect POSTing to be
> > possible afte
On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> It also explicitly states that Windows 2000 and XP don't support this,
> which leads me to suspect that vendors no longer expect POSTing to be
> possible after initial system boot.
No, it means that some of my ATI car
On Thu, 2005-02-10 at 21:25 +0200, Ville SyrjÃlà wrote:
> BTW it seems that old ATI cards use the BIOS to initialize secondary
> adapters even under Windows.
> See http://www.ati.com/support/infobase/3663.html.
It also explicitly states that Windows 2000 and XP don't support this,
which leads me
Hi!
> >>Rumors say that notebooks no longer have video bios at C000h:0; rumors
> >>say that video BIOS on notebooks is simply integrated into main system
> >>BIOS. I personaly do not know if rumors are true, but PCs are ugly
> >>machines
> >>
BTW it seems that old ATI cards use the BIOS to initialize secondary
adapters even under Windows.
See http://www.ati.com/support/infobase/3663.html.
--
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
Alan Cox wrote:
On Sad, 2005-02-05 at 09:35, Pavel Machek wrote:
Rumors say that notebooks no longer have video bios at C000h:0; rumors
say that video BIOS on notebooks is simply integrated into main system
BIOS. I personaly do not know if rumors are true, but PCs are ugly
machines
Hi!
> > > > We already try to do that, but it hangs on 70% of machines. See
> > > > Documentation/power/video.txt.
> > >
> > > We know that all of these ROMs are run at power on so they have to
> > > work. This implies that there must be something wrong with the
> > > environment the ROM are bein
Pavel Machek <[EMAIL PROTECTED]> writes:
> Hi!
>
> > > We already try to do that, but it hangs on 70% of machines. See
> > > Documentation/power/video.txt.
> >
> > We know that all of these ROMs are run at power on so they have to
> > work. This implies that there must be something wrong with th
On Mon, 7 Feb 2005, Carl-Daniel Hailfinger wrote:
And how many competing implementations of video helpers/emulation code
do we have now?
- scitechsoft emu
- linuxbios emu
- etc. (I surely forgot some)
just a minor nit-pick. "linuxbios" is not an "emulator" but drop-in
replacement for commerical bi
On Mon, 2005-02-07 at 07:27, Paulo Marques wrote:
> I still don't have hard numbers from the work Li-Ta Lo is doing (I'm
> CC'ing him on this thread to see if he can shed some light here), but I
> guess that you could have the complete emulator for about 50kB of code.
The difference between the
On Mon, 2005-02-07 at 09:01, Pavel Machek wrote:
> Hi!
>
> > > 3 - it's always there and can be executed at *any* time: booting,
> > > returning from suspend, etc. Also it would allow the VESA framebuffer
> > > driver to change graphics mode at any time (for instance).
> >
> > OK, and what would
Hi!
> > 3 - it's always there and can be executed at *any* time: booting,
> > returning from suspend, etc. Also it would allow the VESA framebuffer
> > driver to change graphics mode at any time (for instance).
>
> OK, and what would force you to do the above in the kernel? If the code
> lives in
Carl-Daniel Hailfinger wrote:
Paulo Marques schrieb:
[...]
It seems to me that x86 emulation in the kernel is the way to go because:
[...]
3 - it's always there and can be executed at *any* time: booting,
returning from suspend, etc. Also it would allow the VESA framebuffer
driver to change graphic
Paulo Marques schrieb:
> Adam Sulmicki wrote:
>
>>
>> hi all,
>> I would like point to work done by Li-Ta Lo.
>>
>> It allows you to completely initalize the VGA BIOS w/out using
>> PC BIOS at all.
>>
>>
>> http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html
>>
Adam Sulmicki wrote:
hi all,
I would like point to work done by Li-Ta Lo.
It allows you to completely initalize the VGA BIOS w/out using
PC BIOS at all.
http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html
unforunatelly the information the web is somewhat s
Hi!
> >The problem with the radeon reset code is that there are many, many
> >variations of the radeon chips, including different steppings of the
> >same part. The ROM is matched to the paticular bugs of the chip. From
> >what I know ATI doesn't even have a universal radeon reset program.
> >
>
Hi!
> > Some systems (intel notably) appear to expect you to use the bios
> > save/restore video state not re-POST.
>
> This works well in many cases, but there are some machines that freeze
> if you attempt to make a VBE state save call. Sadly, I don't have any
> access to an affected machine, s
On Sun, 2005-02-06 at 16:02 +, Alan Cox wrote:
> Some systems (intel notably) appear to expect you to use the bios
> save/restore video state not re-POST.
This works well in many cases, but there are some machines that freeze
if you attempt to make a VBE state save call. Sadly, I don't have a
Jon Smirl wrote:
On Sat, 5 Feb 2005 17:48:43 +0100, Stefan DÃsinger
<[EMAIL PROTECTED]> wrote:
The reset code of radeon card seems to be easy to reverse engineer. I have
started an attempt and I have 50-60% of my radeon M9 reset code implemented
in a 32 bit C program. I had to stop due to school
hi all,
I would like point to work done by Li-Ta Lo.
It allows you to completely initalize the VGA BIOS w/out using
PC BIOS at all.
http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html
unforunatelly the information the web is somewhat spar
On Sad, 2005-02-05 at 09:35, Pavel Machek wrote:
> Rumors say that notebooks no longer have video bios at C000h:0; rumors
> say that video BIOS on notebooks is simply integrated into main system
> BIOS. I personaly do not know if rumors are true, but PCs are ugly
> machines
>
Am Samstag, 5. Februar 2005 18:38 schrieb Jon Smirl:
> On Sat, 5 Feb 2005 17:48:43 +0100, Stefan Dösinger
>
> <[EMAIL PROTECTED]> wrote:
> > The reset code of radeon card seems to be easy to reverse engineer. I
> > have started an attempt and I have 50-60% of my radeon M9 reset code
> > implemented
On Saturday, February 05, 2005 4:07 pm, Jon Smirl wrote:
> After thinking about this for a while I believe the solution is for
> bridges that implement a legacy space to export legacy_io/mem in
> sysfs. So in the ia64 world, all bridges would export these attributes
> since each bridge creates a un
On Sun, 06 Feb 2005 09:42:32 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> I think it could be as simple as an additional sysfs entry
> "legacy_enabled" added to all "VGA" devices in the system at the PCI
> layer level. Toggling it triggers the "untoggling" of all others,
> including
After thinking about this for a while I believe the solution is for
bridges that implement a legacy space to export legacy_io/mem in
sysfs. So in the ia64 world, all bridges would export these attributes
since each bridge creates a unique legacy space.
In the x86 and I believe the ppc world, only
> If they all point to the same space, I can't tell whether I have three
> legacy spaces or one. I need to know how many legacy spaces there are
> in order to know how many VGA cards can simultaneously be enabled.
You don't need to care about this, at least in userland. All you need
is proper pri
On Sat, 5 Feb 2005 17:48:43 +0100, Stefan Dösinger
<[EMAIL PROTECTED]> wrote:
> The reset code of radeon card seems to be easy to reverse engineer. I have
> started an attempt and I have 50-60% of my radeon M9 reset code implemented
> in a 32 bit C program. I had to stop due to school reasons.
The
Am Samstag, 5. Februar 2005 16:47 schrieb Jon Smirl:
> On Sat, 05 Feb 2005 12:53:37 +0100, Ondrej Zary
>
> <[EMAIL PROTECTED]> wrote:
> > I wonder how this can work:
> > a motherboard with i815 chipset (integrated VGA), Video BIOS is
> > integrated into system BIOS
> > a PCI card inserted into one
On Sat, 05 Feb 2005 08:15:35 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-02-04 at 21:30 -0500, Jon Smirl wrote:
>
> > I suspect the problem in that case is a compressed VBIOS. Some laptops
> > compress the VBIOS and the system BIOS into a single ROM and then
> > expand them at
On Sat, 5 Feb 2005 10:37:40 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > I do not understand how initramfs fits into picture... Plus lot of
> > > people (me :-) do not use initramfs...
> >
> > The final fix for this will include the video reset app on initramfs.
> > I already have code in t
On Sat, 05 Feb 2005 12:53:37 +0100, Ondrej Zary
<[EMAIL PROTECTED]> wrote:
> I wonder how this can work:
> a motherboard with i815 chipset (integrated VGA), Video BIOS is
> integrated into system BIOS
> a PCI card inserted into one of the PCI slots, configured as primary in
> system BIOS
The info
On Sat, 2005-02-05 at 12:53 +0100, Ondrej Zary wrote:
> I wonder how this can work:
> a motherboard with i815 chipset (integrated VGA), Video BIOS is
> integrated into system BIOS
> a PCI card inserted into one of the PCI slots, configured as primary in
> system BIOS
The issue seems to be speci
Matthew Garrett wrote:
On Fri, 2005-02-04 at 21:30 -0500, Jon Smirl wrote:
I suspect the problem in that case is a compressed VBIOS. Some laptops
compress the VBIOS and the system BIOS into a single ROM and then
expand them at power on. Sounds like this is not happening on resume.
To get around th
Pavel Machek wrote:
Hi!
We already try to do that, but it hangs on 70% of machines. See
Documentation/power/video.txt.
We know that all of these ROMs are run at power on so they have to
work. This implies that there must be something wrong with the
environment the ROM are being run in. Video ROMs
Hi.
On Sat, 2005-02-05 at 20:37, Pavel Machek wrote:
> Hi!
>
> > > I do not understand how initramfs fits into picture... Plus lot of
> > > people (me :-) do not use initramfs...
> >
> > The final fix for this will include the video reset app on initramfs.
> > I already have code in the kernel f
Hi!
> > I do not understand how initramfs fits into picture... Plus lot of
> > people (me :-) do not use initramfs...
>
> The final fix for this will include the video reset app on initramfs.
> I already have code in the kernel for telling the primary video card
> from secondary ones. When the ke
Hi!
> > We already try to do that, but it hangs on 70% of machines. See
> > Documentation/power/video.txt.
>
> We know that all of these ROMs are run at power on so they have to
> work. This implies that there must be something wrong with the
> environment the ROM are being run in. Video ROMs mak
On Fri, 2005-02-04 at 21:30 -0500, Jon Smirl wrote:
> I suspect the problem in that case is a compressed VBIOS. Some laptops
> compress the VBIOS and the system BIOS into a single ROM and then
> expand them at power on. Sounds like this is not happening on resume.
> To get around the problem copy
On Sat, 05 Feb 2005 02:17:22 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> On laptops, it's frequently the case that c000:0003 will jump to a
> section of code that is no longer mapped into the address space.
> Instead, it's entirely possible that some other section of BIOS will be
> mapped t
On Fri, 2005-02-04 at 21:09 -0500, Jon Smirl wrote:
> How does the hardware die? Are you sure that it is not simply a bug in
> the program doing the POST? Look at the scitech source and you will
> see many BIOS quirks that have to be emulated in order for the post to
> work. If your post program i
On Sat, 05 Feb 2005 02:04:49 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-02-04 at 12:31 -0500, Jon Smirl wrote:
>
> > Fixing this at kernel boot (resume) time will let user space apps
> > assume that all video cards are reset. That removes a lot of
> > complexity from the user
On Fri, 2005-02-04 at 12:31 -0500, Jon Smirl wrote:
> Fixing this at kernel boot (resume) time will let user space apps
> assume that all video cards are reset. That removes a lot of
> complexity from the user space apps (like X).
This can't be the default on x86. I have hardware that will die if
On Sat, 05 Feb 2005 01:52:23 +0100, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> My problem (Samsung P35) is that the BIOS wants to call code which
> is no longer mapped because the BIOS is too big to fit into the
> standard area. Since that additional area has been overwritten, we
> are out
Xavier Bestel schrieb:
> Le vendredi 04 fÃvrier 2005 Ã 00:03 -0500, Jon Smirl a Ãcrit :
>
>>Doing this in user space lets you have two reset
>>programs, vm86 and emu86 for non-x86 machines.
>
>
> Perhaps only emu86 should be used, to have a well-debugged codepath on
> all archs (amd64, ppc, ...)
James Simmons schrieb:
>>>int video_helper(struct video_actions *what_to_do)
>>
>>I do not know, synchronously executing userland code from kernel seems
>>like wrong thing to do.
>
> I'm not a fan for this either. The good news is most graphics cards don't
> require these tricks. The only ones th
Pavel Machek schrieb:
>
> I do not understand how initramfs fits into picture... Plus lot of
> people (me :-) do not use initramfs...
Well, an initrd which is never unmounted should work, too. On SUSE,
"mkdir /initrd" and see what you've been missing. I don't know why
that directory doesn't exist
> > int video_helper(struct video_actions *what_to_do)
>
> I do not know, synchronously executing userland code from kernel seems
> like wrong thing to do.
I'm not a fan for this either. The good news is most graphics cards don't
require these tricks. The only ones that do are the ix86 cards. T
Jon Smirl schrieb:
> On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
>
>>We already try to do that, but it hangs on 70% of machines. See
>>Documentation/power/video.txt.
>
> We know that all of these ROMs are run at power on so they have to
> work. This implies that the
> > /sys/class/pci_bus I show three buses. You wouldn't want the
> > legacy_io/mem attributes on each of these three buses since that
> > implies three independent address spaces.
> >
> > [EMAIL PROTECTED] pci_bus]$ ls /sys/class/pci_bus
> > :00 :01 :02
>
> In that case they'll all p
> Jon does your emulator sit on top of the new legacy I/O and memory APIs? I
> added them for this very reason, though atm only ia64 supports them. There's
> documentation in Documentation/filesystems/sysfs-pci.txt if you want to take
> a look. On kernels that support it, sysfs can be a one
On Friday, February 4, 2005 2:59 pm, Jon Smirl wrote:
> Can you build a no-op version of these that will run on the x86? That
> would allow a single user space API for x86, ia64. Maybe the ppc
> people will join too.
Shouldn't be too hard I think.
> Why does this appear in /sys/class/pci_bus/
On Fri, 4 Feb 2005 10:10:12 -0800, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Jon does your emulator sit on top of the new legacy I/O and memory APIs? I
> added them for this very reason, though atm only ia64 supports them. There's
> documentation in Documentation/filesystems/sysfs-pci.txt if you
> I would prefer to use hotplug for the user space call out but when I
> do I run into the framebuffer and DRM drivers. This having multiple
> drivers for the same piece of hardware is a pain. So hotplug on the
> standard device is not an option.
I know. It could be merged. The secert is a gradua
On Fri, 4 Feb 2005 10:10:12 -0800, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Jon does your emulator sit on top of the new legacy I/O and memory APIs? I
> added them for this very reason, though atm only ia64 supports them. There's
> documentation in Documentation/filesystems/sysfs-pci.txt if you
On Friday, February 4, 2005 9:31 am, Jon Smirl wrote:
> For non-x86 systems put an emu version on initramfs. My statically
> linked against klibc x86 reset app is about 15K. The emu version is
> significantly bigger but there is no way to avoid it if you are using
> x86 hardware in a non-x86 box.
On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
> We already try to do that, but it hangs on 70% of machines. See
> Documentation/power/video.txt.
We know that all of these ROMs are run at power on so they have to
work. This implies that there must be something wrong wit
On Fri, 4 Feb 2005 17:30:19 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
> I do not understand how initramfs fits into picture... Plus lot of
> people (me :-) do not use initramfs...
The final fix for this will include the video reset app on initramfs.
I already have code in the kernel for telli
Hi!
> > 3) The user space reset programs have to be serialized because of the
> > rule about only a single VGA at a time. Calling vm86 from kernel mode
> > is not a good idea. Doing this in user space lets you have two reset
> > programs, vm86 and emu86 for non-x86 machines.
>
> With the approach
Hi!
> >>What about simply blocking all video accesses before disk (etc) is
> >>resumed, so that "normal" (not locked in memory) application can be
> >>used?
> >
> > Very bad for debugging. Genuine serial ports are becoming rarer.
>
> As a bonus, even genuine serial ports may be in undefined stat
Le vendredi 04 fÃvrier 2005 Ã 00:03 -0500, Jon Smirl a Ãcrit :
> Doing this in user space lets you have two reset
> programs, vm86 and emu86 for non-x86 machines.
Perhaps only emu86 should be used, to have a well-debugged codepath on
all archs (amd64, ppc, ...)
As it's usermode, the code size is l
On Fri, 2005-02-04 at 13:17 +0100, Carl-Daniel Hailfinger wrote:
> Jon Smirl schrieb:
> > A starting place for a user space reset program:
> > ftp://ftp.scitechsoft.com/devel/obsolete/x86emu/x86emu-0.8.tar.gz
> >
> > This thread talks about the VGA routing code:
> > http://lkml.org/lkml/2005/1/17/
Jon Smirl schrieb:
> Reseting a video card from suspend is essentially the same problem as
> reseting secondary video cards on boot. The same code can address both
> problems.
>
> Some things to consider
>
> 1) With multiple video cards you have to ensure only a single VGA gets
> enabled. Run
On Friday 04 February 2005 11:32, Carl-Daniel Hailfinger wrote:
> Oliver Neukum schrieb:
> > Am Freitag, 4. Februar 2005 08:48 schrieb Pavel Machek:
> >>What about simply blocking all video accesses before disk (etc) is
> >>resumed, so that "normal" (not locked in memory) application can be
> >>use
Oliver Neukum schrieb:
> Am Freitag, 4. Februar 2005 08:48 schrieb Pavel Machek:
>
>>What about simply blocking all video accesses before disk (etc) is
>>resumed, so that "normal" (not locked in memory) application can be
>>used?
>
> Very bad for debugging. Genuine serial ports are becoming rarer
Am Freitag, 4. Februar 2005 08:48 schrieb Pavel Machek:
> What about simply blocking all video accesses before disk (etc) is
> resumed, so that "normal" (not locked in memory) application can be
> used?
Very bad for debugging. Genuine serial ports are becoming rarer.
Regards
Hi!
> > I'd love to see it too. Pavel, even if you don't want to merge it for a
> > while, we can always incorporate it in the Suspend2 patches so it gets
> > some testing. I know I'd try it on my i830 based Omnibook.
>
> Can we use call_usermodehelper at this early resume stage (before any
> vid
Hi!
> > > User has triggered resume
> > > run wakeup.S
>
> wakeup.S runs in real mode. Why can't it just call the VBIOS at
> C000:0003 to reset the hardware before setting the mode?
We already try to do that, but it hangs on 70% of machines. See
Documentation/power/video.txt.
Hi!
> Reseting a video card from suspend is essentially the same problem as
> reseting secondary video cards on boot. The same code can address both
> problems.
Well, it is made more tricky by the fact that you are running during
resume -- hard to debug. Ideally you want to have video so you can
On Fri, 04 Feb 2005 13:51:55 +1100, Nigel Cunningham
<[EMAIL PROTECTED]> wrote:
> > User has triggered resume
> > run wakeup.S
wakeup.S runs in real mode. Why can't it just call the VBIOS at
C000:0003 to reset the hardware before setting the mode?
--
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe
Reseting a video card from suspend is essentially the same problem as
reseting secondary video cards on boot. The same code can address both
problems.
Some things to consider
1) With multiple video cards you have to ensure only a single VGA gets
enabled. Running video reset on a card is going
Hi.
On Fri, 2005-02-04 at 13:35, Carl-Daniel Hailfinger wrote:
> Can we use call_usermodehelper at this early resume stage (before any
> video access)? Calling vm86 directly is probably not going to fly
> because we want to be shielded from any misbehaviour in the bios code
> and it may be necessa
Hi!
Nigel Cunningham wrote:
> Hi.
>
> On Fri, 2005-02-04 at 09:54, Pavel Machek wrote:
>
>>Hi!
>>
>>
>Are you able to use framebuffer(radeonfb,1024x768) with this
>configuration or do you need to use plain vga-console for it to work?
No.
For a working framebuffer console you
83 matches
Mail list logo
