those
calls more complex?
No, there does not need to be graphical images of the text console -- a
simply text buffer would suffice. But what about things like GTKFb and
Embedded QT? They would certainly benefit from having a backup screen
image, right? I do not believe there is any way to determi
as a PM client and doing the above when the
fbdev suspend/resume hooks are called should work. A memory backup is
worked on until the resume is run and the backup is restored to the
display.
So the fbdev drivers would register PM with fbcon, not PCI, correct?
Brad Douglas
[EMAIL PROTECTED]
http:
software, drivers, etc.)
You may consult http://sourceforge.net/projects/linux-fbdev for
subscribe information.
Brad Douglas
[EMAIL PROTECTED]
http://www.linux-fbdev.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
y relative
> > to each other, and were both in normal Earth gravity.
>
> The kernel blocks interrupts during console output. fbdev
> consoles are slow. Net result: many lost timer interrupts.
>
> I'm working on it. Slowly. Should have something next week.
You may w
x27;ll fix your APM problems, at a minimum. Anyone who
wants it can email me privately, since the site I put it up on no longer
exists...
Brad Douglas
[EMAIL PROTECTED]
http://www.linux-fbdev.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
p XFree86's ass? But the author
was talking about writing kernel drivers *for* Xfree86... You are
correct in the fact that this will never happen. But as far as video in
the kernel, you are wrong.
Brad Douglas
[EMAIL PROTECTED]
http://www.linux-fbdev.org
-
To unsubscribe from this list: s
an 80x80, I would like for it to take
> up the whole screen.
>
> Thanks in advance.
Search for a program called fblogo. Sorry, I don't have a link handy,
but it's widely avaliable.
Thanks,
Brad Douglas
[EMAIL PROTECTED]
http://www.linux-fbdev.org
-
To unsubscribe from this l
ler: Silicon Integrated Systems [SiS]:
Unknown device 6300
> (rev 11)
Your particular chipset (actually, a 6300, which is different than the
630) is not supported by the SIS frame buffer. If this chipset is a
VESA 2.0+ compatible controller, then you will be able to use the VESA
frame buffer.
Brad
Alan,
Here's a patch that fixes the Makefile and Config.in for drivers/video in
regard to the ATI Rage128. This will allow it to properly be compiled as
a module with proper defaults.
No idea what happened to this... Looks like it's been broke for some
time.
Brad Douglas
[EMAIL
adeon
For ATI's Mach64 based cards, they chose to let the vendor pick the DAC
that best suited their needs. While this is good from an economical
perspective, it caused massive support headaches. Needless to say, ATI
no longer uses this model. It's not that they refused to publish
drive
t's the BIOS revision it claims to have during POST? It should be
A0x (where x is a number).
Thanks,
Brad Douglas
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
ecause 2.2.18 is the 1st release
> in a while that works well on PPC, and lots of PPCs have a rage128.
Also, this patch to make it compile as module. How did these get removed?
I could have swore they used to work fine.
Sorry for the attachment. This computer has evolution.
Brad Douglas
eople were to talk to.
Once I get the OK from Compal (and finish testing), I'll post it to the
Tuxtops support site for all to download.
Brad Douglas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
DMI 2.3 present.
50 structures occupying 1477 bytes.
DMI table at 0x000EC230.
Handle 0x
DMI
The aty128fb patch is good.
> Did anybody test these patches? Currently any user can crash the kernel by
> abusing this bug.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> -- Forwarded message --
> Date: Sat, 14 Oct 2000 18:21:25 +0200 (CEST)
The aty128fb patch is good.
> Did anybody test these patches? Currently any user can crash the kernel by
> abusing this bug.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> -- Forwarded message --
> Date: Sat, 14 Oct 2000 18:21:25 +0200 (CEST)
lready multiple versions of the
BIOS for this machine already, so I initially discounted that method. It also means a
bit of upkeep, too.
I was really hoping for a "set it and forget it" approach, but that doesn't seem
possible.
Brad Douglas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-
To
st we can do build a list of the systems that
are the same, but it's certainly not a preferred way.
Any suggestions?
Brad Douglas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
there a way to uniquely identify the affected BIOSes at boot time and
> turn off APM? According to Brad Douglas, the 32-bit Get Power Status
> (0AH) call is broken.
I do not believe so. I tend to think that detecting these broken models is a waste of
kernel code (especially, if there
iled bug reports on this same problem, again with no
> response.
>
> http://linuxcare.com.au/cgi-bin/apm/incoming?id=90
> http://linuxcare.com.au/cgi-bin/apm/incoming?id=91
We have an open ticket with Compal (the manufacturer) about the problem. The 32-bit
Get Power Status (0AH)
19 matches
Mail list logo
