Re: [PATCH] vt_buffer: drop console buffer copying optimisations
On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone dan...@fooishbar.org wrote:
On 5 February 2015 at 11:35, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
If I'm not mistaken, that would be as simple as adding
#define VT_BUF_HAVE_RW.
#define scr_writew(val, addr) (*(addr) = (val))
#define scr_readw(addr) (*(addr))
to arch/x86/include/asm/vga.h.
and stick an
#if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
#endif
around that and its sorted as an option everyone can leave off but the
afflicted.
Well, given all the distros will enable that, might as well be #if
!defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).
All distros on 1 out of 29 architectures?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vt_buffer: drop console buffer copying optimisations
On Tue, Feb 3, 2015 at 4:54 PM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
On Thu, 29 Jan 2015 15:40:33 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie airl...@redhat.com wrote:
Linus, this came up a while back I finally got some confirmation
that it fixes those servers.
I'm certainly ok with this. which way should it go in? The users are:
- drivers/tty/vt/vt.c (Greg KH, tty layer)
- drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)
and it might make sense to have *some* indication of how much worse
this makes fbcon performance in particular..
For devices that have no hardware scrolling it used to be double digit
percentages difference between 32 and 64bit when reading from the fb
because the reads are not posted and the latency killed you. Writes - not
so big a deal - but the bridge should combine them anyway. I imagine
16bit read would be unprintably bad.
Fbcon uses scr_mem{cpy,move}w() for the VT buffer (characters + attributes)
only, not for the frame buffer data.
So the performance degradation should be minimal.
However, as this affects real VGA on x86 only, perhaps it can be fixed
in arch/x86/include/asm/vga.h instead of include/linux/vt_buffer.h, so
platforms not having VGA are not affected? We have these VT_BUF_*
and scr_*() abstractions for a reason...
If I'm not mistaken, that would be as simple as adding
#define VT_BUF_HAVE_RW.
#define scr_writew(val, addr) (*(addr) = (val))
#define scr_readw(addr) (*(addr))
to arch/x86/include/asm/vga.h.
If someone wants to put one of the bad VGA cards in a non-x86 PCI slot,
perhaps a few more architecture-specific asm/vga.h have to be updated:
$ git grep -w VT_BUF_HAVE_RW -- arch
arch/alpha/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/mips/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/powerpc/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/sparc/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/tile/include/asm/vga.h:#define VT_BUF_HAVE_RW
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Fix support for PCI domains
On Fri, Aug 6, 2010 at 05:55, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
(For some reason I thought that went in ages ago ...)
This fixes support for PCI domains in what should hopefully be a backward
compatible way along with a change to libdrm.
When the interface version is set to 1.4, we assume userspace understands
domains and the world is at peace. We thus pass proper domain numbers
instead of 0 to userspace.
The newer libdrm will then try 1.4 first, and fallback to 1.1, along with
ignoring domains in the later case (well, except on alpha of course)
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/drm_ioctl.c | 1 +
include/drm/drmP.h | 18 +-
include/drm/drm_core.h | 2 +-
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c1b9871..6d4bad5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1071,11 +1071,19 @@ static __inline__ int drm_core_check_feature(struct
drm_device *dev,
return ((dev-driver-driver_features feature) ? 1 : 0);
}
-#ifdef __alpha__
-#define drm_get_pci_domain(dev) dev-hose-index
-#else
-#define drm_get_pci_domain(dev) 0
-#endif
+static inline int drm_get_pci_domain(struct drm_device *dev)
+{
+#ifndef __alpha__
+ /* For historical reasons, drm_get_pci_domain() is busticated
+ * on most archs and has to remain so for userspace interface
+ * 1.4, except on alpha which was right from the beginning
+ */
+ if (dev-if_version 0x10004)
+ return 0;
+#endif /* __alpha__ */
+
+ return pci_domain_nr(dev-pdev-bus);
error: implicit declaration of function ‘pci_domain_nr’
on m68k without PCI.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel KMS + fbcon + Mplayer
On Wed, Apr 29, 2009 at 12:04, Peter Hanzel hanzelpe...@gmail.com wrote:
I have tried Intel KMS in kernel 2.6.91.1 with fbcon. I am using only
framebuffer console.
Most fb apps works, but I have problem with mplayer.
The init works but the video is badly displayed.
I have investigated the problem and found, that for my laptop mode
1280x800-32.
The ioctl on /dev/fb0 FBIOGET_VSCREENINFO returns.
var.bits_per_pixel=32
var.transp.length = 0.
So the mplayer thinks we are in 24 bit mode (maybe this is bug in mplayer,
because bits_per_pixel is 32).
But next I have checked it with kernel vesafb and for same mode
(1280x800-32, vga=0x362 )
The fb ioctl returns
var.bits_per_pixel=32
var.transp.length = 8.
So is this intentionally made so. Because I think this mode use only red,
green,blue and no transp. But for one pixel you must write 4 bytes. (so
transp is not used).
That must be a bug in mplayer, as var.bits_per_pixel = 32. If there's
no transparency, it's
correct to hav var.transp.length = 0 . The additional 8 bits may be unused.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/3] allow console unregistration
Hi Tony,
On Wed, 30 May 2007, Antonino A. Daplas wrote:
On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote:
Randy just informed me that the patch limits are bigger now, so here are the
actual patches.
This patch allows for proper console unregistration via the VT layer, and
updates the FB layer to use it. This makes debugging new console drivers
much easier, since you can properly clean them up before unloading.
Antonio already checked it out (and suggested a tweak for the fbcon side)
so I think it's on its way already via the FB tree.
Jesse,
I already implemented (and tested) selective framebuffer/console
unregistration in my tree using your patch as a base. I'll send this
patch to akpm soon.
Geert,
Is this something that you might need for ps3fb? It should address 2 of
your concerns. The only thing is that you will need
CONFIG_VT_HW_CONSOLE_BINDING=y. You can default this to 'y' in your
platform, or select it.
I was going to look at Jesse's patch, but it didn't happen yet.
So yes, I'm definitely interested in your patch! Can you please send it to
linux-fbdev-devel already?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 B-1935 Zaventem, Belgium
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] CRTC scanout buffer types
On Mon, 8 Aug 2005, Antonino A. Daplas wrote:
Jon Smirl wrote:
How does this work, is one 24 bit color the key?
32 bpp indexed+RGB 888 with color key to enable RGB888
This is directcolor. Each component is indexed.
No, directcolor is different. This is a mode that combines a pseudocolor
CLUT256 visual (but only 255 colors, because of the color key) with a truecolor
RGB888 visual.
E.g. the Matrox Millennium can do this, and IIRC at least Accelerated X
supports it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] CRTC scanout buffer types
On Sun, 7 Aug 2005, Jon Smirl wrote:
On 8/7/05, Antonino A. Daplas [EMAIL PROTECTED] wrote:
Vladimir Dergachev wrote:
I agree that something like the above is acceptable, exept that we need
an extra field for offset and another if indexed color or not. So
something like:
A:2/0/R:10/2/G:10/12/B:10/22//I
The offsets are not needed as part of the input, they should be part
of the output display. It is the chip driver that will determine the
offsets, not the user.
So you cannot select between RGB and BGR on hardware that allows to select
that?
The only exception I can think of is that the radeon hardware can
control which nibble is used in 4bpp. I'd say if you need that kind of
This is something completely different, since each nibble is a different pixel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] CRTC scanout buffer types
On Fri, 5 Aug 2005, Jon Smirl wrote:
I've included the scanout types for the R200, what other ones are
supported by the various chips? For example I think the R300 can
scanout in floating point.
1 bpp monochrome (black = 0 and white = 1 or vice versa)
1 bpp indexed
2 bpp indexed
3 bpp indexed
4bpp Indexed
4 bpp greyscale
5 bpp indexed
6 bpp indexed
7 bpp indexed
8bpp Indexed
8 bpp monochrome (black is all zeroes and white is all ones or vice versa)
8 bpp greyscale
8 bpp RGB 332
16bpp aRGB 1555
16bpp RGB 565
16bpp aRGB
24bpp RGB 888
24 bpp aRGB
32bpp aRGB
32 bpp indexed+RGB 888 with color key to enable RGB888
16bpp aIndex 88
This one is a new one for me ;-)
32bpp aRGB 2:10:10:10 palette bypassed
And of course all the various YCbCr (4:4:4, 4:2:2, 4:2:0) variants, which just
need a few additional FB_VISUAL_* defines :-)
Probably I forgot a few. Feel free to add them.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] CRTC scanout buffer types
On Sun, 7 Aug 2005, Jon Smirl wrote:
I'm trying to work out a syntax for the sysfs attribute that will
control the config. My first idea is to use a alpha/red/blue/green
syntax. When red is set and blue/green are missing index mode is set.
When green is set and red/blue are missing gray scale is set.
Ugh, sounds complex and non-intuitive...
Are there chips that can scanout from buffers not packed at a power of two?
Yes, planar frame buffers can.
How should I work different color spaces (YCbCr) into this?
That's more like a visual thing. Using a YCbCr visual, we could say the red,
green, and blue bitfields actually control Y, Cb, and Cr.
4bpp Index = /4
4bpp greyscale = //4
8bpp Index = /8
8bpp RGB 332 = /3/3/2
8bpp greyscale = //8
16bpp aRGB 1555 = 1/5/5/5
16bpp RGB 565 = /5/6/5
16bpp aRGB = 4/4/4/4
16bpp aIndex 88 = 8/8
24bpp RGB 888 = /8/8/8
24bpp aRGB = 6/6/6/6
32bpp aRGB = 8/8/8/8
32bpp aRGB 2:10:10:10 = 2/10/10/10
BTW, the numbers still control the lengths of the color bitfields only, not
their positions. E.g. some hardware does ARGB, other does ABGR, or BGRA...
1 bpp monochrome (black = 0 and white = 1 or vice versa)
1 bpp indexed
2 bpp indexed
3 bpp indexed
5 bpp indexed
6 bpp indexed
7 bpp indexed
These would have the same config, //8, right? You then just control
what you write to the byte.
No, they use bitplanes.
How does this work, is one 24 bit color the key?
32 bpp indexed+RGB 888 with color key to enable RGB888
Actually one of the CLUT index values is the color key.
So if the pixel has [ i | r | g | b ], the actual color is:
if (i == key)
color = [ r, g, b ];
else
color = [ clut.r[i], clut.g[i], clut.b[i] ];
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM depends on ???
On Sun, 29 May 2005, Kyle Moffett wrote:
On May 29, 2005, at 15:58:10, Geert Uytterhoeven wrote:
What Kyle said is the correct answer... we either keep this lovely
construct (I'll add a comment for 2.6.13) or we go back to the old
intermodule or module_get stuff... DRM built-in with modular AGP is always
wrong... or at least I'll get a hundred e-mails less every month if I
say it is ..
And what if we don't have AGP at all? Or no PCI?
Then DRM detects that at configure time and excludes the code that requires
AGP. Basically, the following are valid configurations:
OK. So we still need the dependency on PCI.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM depends on ???
On Mon, 30 May 2005, Dave Airlie wrote:
OK. So we still need the dependency on PCI.
at the moment yes but I'm think we will have to remove this as soon as
we get the Sparc ffb stuff up and running again, the ffb driver
doesn't do any PCI stuff, we have some code around but we haven't had
any testing done on it and I'm sure its rotting away, if a maintainer
turns up for sparc ffb, then the PCI requirement is gone..
So you will have to change it to 'PCI || (FB_SBUS SPARC64)', right?
Simply dropping the PCI requirement is wrong.
I can add the PCI dependency for now...
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] DRM depends on ???
DRM depending on `AGP=n' is driving me crazy! How to make CONFIG_DRM not
eligible for selection on platforms that do not have AGP?
Since many of the core DRM files depend on PCI, add a dependency on PCI,
to minimize the damage.
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
--- linux-2.6.12-rc5/drivers/char/drm/Kconfig 2005-05-25 19:37:53.0
+0200
+++ linux-m68k-2.6.12-rc5/drivers/char/drm/Kconfig 2005-04-05
10:12:41.0 +0200
@@ -6,7 +6,7 @@
#
config DRM
tristate Direct Rendering Manager (XFree86 4.1.0 and higher DRI
support)
- depends on AGP || AGP=n
+ depends on (AGP || AGP=n) PCI
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] 3dfx DRM depends on PCI
3dfx DRM depends on PCI
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
--- linux-2.6.12-rc1/drivers/char/drm/Kconfig 2005-01-22 09:28:00.0
+0100
+++ linux-m68k-2.6.12-rc1/drivers/char/drm/Kconfig 2005-01-17
22:51:02.0 +0100
@@ -18,7 +18,7 @@ config DRM
config DRM_TDFX
tristate 3dfx Banshee/Voodoo3+
- depends on DRM
+ depends on DRM PCI
help
Choose this option if you have a 3dfx Banshee or Voodoo3 (or later),
graphics card. If M is selected, the module will be called tdfx.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Thu, 17 Mar 2005, Ville [iso-8859-1] Syrjl wrote:
On Thu, Mar 17, 2005 at 12:12:58PM +1100, Benjamin Herrenschmidt wrote:
I understand you can't have userspace program the accelerator while
someone else is doing the same thing. Oh and I now understand that the
same really applies to direct framebuffer access due to the swapper.
And you can't have someone program the accelerator while somebody does
direct access neither. It's basically all exclusive.
I haven't seen that happen on any hardware I own. Matrox specs explicitly
mention that there is no need to synchronize accelerator and direct
framebuffer access.
Really? I was always given Matrox as an example of a card that would lock up if
you access the frame buffer while the accelerator is busy...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrjl wrote:
I think that making the assumption that all memory is preserved when the
memory layout (virtual resolution and depth) doesn't change is perfectly
valid too. That would allow X to do it's Ctrl-Alt-+ and - things without
repainting the whole screen.
Indeed. The `geometry' part of the screen isn't changed, only the `timings'
part (cfr. the split of fb_var_screeninfo parameters I did in fbutils (which
BTW wasn't ever finished).
If radeonfb will allocate the buffer for the second head from the top of
the memory users would basically have to guess it's location. matroxfb
simply cuts the memory in two pieces and allocates the buffers from the
start of each piece. I don't really like that approach. Adding a simple
byte_offset field to fb_var_screeninfo would solve the problem quite
nicely but I don't know if such API changes are acceptable at this stage.
You wouldn't have to guess its location, look at fix.smem_start.
I once did a similar thing for an embedded prototype: take a fixed amount of
memory for both frame buffers (this was a UMA system), fb0 starts from the top,
fb1 starts from the bottom. You can enlarge each frame buffer, until you read
the memory of the other. Each fix.smem_{start,len} corresponds exactly to the
memory allocated to each frame buffer.
Of course, if you also want off-screen memory (i.e. memory beyond
xres_virtual*yres_virtual*bpp/8), things get more complicated, since currently
there's no way for the application to ask for a minimum amount of off-screen
memory. Perhaps a new field in fb_var_screeninfo (and zero means `I don't
care', for backwards compatibility).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
Re: [Linux-fbdev-devel] New kernel API for ROMs
On Fri, 6 Aug 2004, Jon Smirl wrote:
This patch provides a new kernel API for access ROMs from device
drivers. If you're working on a driver that uses the ROM (most video
drivers) please give this patch a try and send some feedback/bugs.
pci_map_rom() - map the rom and provide virtual address, transparently
return shadow/copy if needed. Normal drivers call this
pci_map_rom_copy() - same as pci_map_rom except the ROM will copied,
future reads of ROM will use copy. Hardware with minimal decoding calls
use this
pci_unmap_rom() - release the ioremap if there is one
The ROMs also appear in sysfs and you can use hexdump to see them.
If the Radeon ROM is all . Load a radeon device driver and it will
appear. Radeon cards have a bug that loading the driver will fix.
+unsigned char *
+pci_map_rom_copy(struct pci_dev *dev, size_t *size) {
+ struct resource *res = dev-resource[PCI_ROM_RESOURCE];
+ unsigned char *rom;
+
+ rom = pci_map_rom(dev, size);
+ if (!rom)
+ return NULL;
+
+ if (res-flags (PCI_ROM_COPY | PCI_ROM_SHADOW))
+ return rom;
+
+ res-start = (unsigned long)kmalloc(*size, GFP_KERNEL);
What's the maximum size of a PCI ROM? Larger than kmalloc() can handle?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] depends on PCI: ATI Rage 128 and Radeon DRM
ATI Rage 128 and Radeon DRM unconditionally depend on PCI
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
--- linux-2.6.8-rc2/drivers/char/drm/Kconfig2004-07-15 23:14:12.0 +0200
+++ linux-m68k-2.6.8-rc2/drivers/char/drm/Kconfig 2004-07-19 18:15:58.0
+0200
@@ -31,7 +31,7 @@
config DRM_R128
tristate ATI Rage 128
- depends on DRM
+ depends on DRM PCI
help
Choose this option if you have an ATI Rage 128 graphics card. If M
is selected, the module will be called r128. AGP support for
@@ -39,7 +39,7 @@
config DRM_RADEON
tristate ATI Radeon
- depends on DRM
+ depends on DRM PCI
help
Choose this option if you have an ATI Radeon graphics card. There
are both PCI and AGP versions. You don't need to choose this to
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Wed, 12 May 2004, James Simmons wrote:
That app must be pretty big if it runs on non intel platforms. You nedd to
translate the x86 BIOS code to native assembly before you run it.
Or interprete it.
On Wed, 12 May 2004, Richard Smith wrote:
Jon Smirl wrote:
licenses). I've already built a very messy prototype by moving the existing
fbdev code to user space and it works just fine. I also called another little
app which executed the VBIOS and reset secondary cards at boot via hotplug.
Is that app available somewhere? I'm trying to get an ATI Rage Mobility
M1 chip up under LinuxBIOS and such and app would be useful for me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Wed, 12 May 2004, James Simmons wrote:
That app must be pretty big if it runs on non intel platforms. You nedd to
translate the x86 BIOS code to native assembly before you run it.
Or interprete it.
Only if we could use Java for the video BIOS.
Java? em86 (written by Gabriel Paubert) has been working fine on my PPC box
since 1998.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Wed, 12 May 2004, James Simmons wrote:
I understand you point of the mode switching code being huge. The embedded
guys require really lean kernels. I have no problem making the mode switching
code modular. I just want to avoid the above overhead.
And for an embedded device with a fixed LCD screen you can easily make the mode
setting code __init, and disallow mode changes after boot up. One device
driver, just one more kernel config option. Some code has to do the mode
setting anyway, so better keep it in one place.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Current discussion about the future of free software graphics
On Tue, 11 May 2004, sottek wrote:
Also, we probably want to drop the communication down to just one
list? I think dri-devel seems to have the widest group of subscribers.
I don't think that's a good idea: dri-devel is limited to the platforms that
have a working DRI implementation, while linux-fbdev-devel is also frequented
by people from platforms without DRI.
And there we see a communication problem again: the DRI was started without
talking to fbdev people, IIRC...
Please unite our forces!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Mon, 10 May 2004, Alan Cox wrote:
On Llu, 2004-05-10 at 17:14, James Simmons wrote:
Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be
moved to userspace. The networking code alone is over 17 megs in size.
Not on my box. Nothing like it. Although to answer that question with a
definitive example ELKS (a Linux like 8086 kernel in 64K) has IP demux
in kernel space and tcp in user space. The v7 NCP stack also had much of
the protocol in user space.
Sounds reasonable, since IP demux touches the hardware, and TCP not.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Fri, 7 May 2004, Nicolas Souchu wrote:
On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote:
BenH and others have made proposals for pushing the mode setting code into a
user space library in order to reduce kernel footprint and ease debugging. Most
of the code needed for this library already exists in the current Linux FB
drivers. I'm not sure if this could be relicensed BSD when it is moved to user
space.
One advantage of true graphic drivers (opposed to VESA or more generally bios modes)
is that they can boot some archs in graphic mode (no text mode) without bios.
Exactly what linuxfb was originaly designed to. How do you perform this from
userspace?
Note that this is `early userspace', in initramfs. Graphics would be
initialized a bit later than today, but (hopefully) still sufficiently early.
Even right now fbcon is initialized later than vgacon, because we need bus
probing before we can detect graphics cards.
If you really need kernel messages earlier, you have to fallback to vgacon
(ugh), a serial console, or an early boot console (like PPC BTEXT).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Thu, 6 May 2004, Jon Smirl wrote:
6) What about low memory embedded systems? mesa has an excellent implementation
of OpenGL-ES available for free. http://www.khronos.org/opengles/ It already
supports running out of a dumb framebuffer. OpenGL-ES is small enough that
Qualcomm is putting it into phones. Of course you can always ignore the GUI
standard and do what you want in an embedded system.
What about performance on older systems? Current new embedded CE may be much
faster than an average PC from a few years ago.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Thu, 6 May 2004, Jon Smirl wrote:
Another topic that I missed was, why did kgi fail and what can we do to avoid
repeating the same path this time around.
IIRC, the main reasons were:
- GGI wanted to do too much at once and was too intruisive (conclusion:
always advance in small steps, not big leaps):
o kernel graphics drivers (KGI)
o new input subsystem (similar to what we're heading to now)
o user space library (libggi, AFAIK the only part that's still alive)
- fbdev was better in multi-platform handling (m68k - PPC - ia32 - SPARC
- alpha - ...)
Please correct me if I'm wrong ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
