[PATCH] Update fbdev fb_fix_screeninfo
If you change the color depth via fbset or some other framebuffer aware
userland application struct fb_fix_screeninfo is not updated to this new
information. This patch fixes this issue. Also the function is changed to
just pass in struct drm_framebuffer so in the future we could use more
fields. I'm hoping some day fix->smem* could be set here :-)
Signed-off-by: James Simmons
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5c4f9b9..0307d60 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -607,6 +607,25 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
}
EXPORT_SYMBOL(drm_fb_helper_fini);
+void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
+{
+ info->fix.type = FB_TYPE_PACKED_PIXELS;
+ info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
+ FB_VISUAL_TRUECOLOR;
+ info->fix.mmio_start = 0;
+ info->fix.mmio_len = 0;
+ info->fix.type_aux = 0;
+ info->fix.xpanstep = 1; /* doing it in hw */
+ info->fix.ypanstep = 1; /* doing it in hw */
+ info->fix.ywrapstep = 0;
+ info->fix.accel = FB_ACCEL_NONE;
+ info->fix.type_aux = 0;
+
+ info->fix.line_length = fb->pitch;
+ return;
+}
+EXPORT_SYMBOL(drm_fb_helper_fill_fix);
+
static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, u16 regno, struct fb_info *info)
{
@@ -816,6 +835,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
mutex_unlock(&dev->mode_config.mutex);
return ret;
}
+ drm_fb_helper_fill_fix(info, fb_helper->fb);
}
mutex_unlock(&dev->mode_config.mutex);
@@ -953,6 +973,7 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper
*fb_helper,
if (new_fb) {
info->var.pixclock = 0;
+ drm_fb_helper_fill_fix(info, fb_helper->fb);
if (register_framebuffer(info) < 0) {
return -EINVAL;
}
@@ -979,26 +1000,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper
*fb_helper,
}
EXPORT_SYMBOL(drm_fb_helper_single_fb_probe);
-void drm_fb_helper_fill_fix(struct fb_info *info, uint32_t pitch,
- uint32_t depth)
-{
- info->fix.type = FB_TYPE_PACKED_PIXELS;
- info->fix.visual = depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
- FB_VISUAL_TRUECOLOR;
- info->fix.mmio_start = 0;
- info->fix.mmio_len = 0;
- info->fix.type_aux = 0;
- info->fix.xpanstep = 1; /* doing it in hw */
- info->fix.ypanstep = 1; /* doing it in hw */
- info->fix.ywrapstep = 0;
- info->fix.accel = FB_ACCEL_NONE;
- info->fix.type_aux = 0;
-
- info->fix.line_length = pitch;
- return;
-}
-EXPORT_SYMBOL(drm_fb_helper_fill_fix);
-
void drm_fb_helper_fill_var(struct fb_info *info, struct drm_fb_helper
*fb_helper,
uint32_t fb_width, uint32_t fb_height)
{
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 67738f3..701e830 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -150,7 +150,6 @@ static int intelfb_create(struct intel_fbdev *ifbdev,
// memset(info->screen_base, 0, size);
- drm_fb_helper_fill_fix(info, fb->pitch, fb->depth);
drm_fb_helper_fill_var(info, &ifbdev->helper, sizes->fb_width,
sizes->fb_height);
info->pixmap.size = 64*1024;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 6d56a54..a26d047 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -359,7 +359,6 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo);
info->screen_size = size;
- drm_fb_helper_fill_fix(info, fb->pitch, fb->depth);
drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width,
sizes->fb_height);
/* Set aperture base/size for vesafb takeover */
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index f7b4762..80c1c7a 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -225,8 +225,6 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,
strcpy(info->fix.id, "radeondrmfb");
- drm_fb_helper_fill_fix(info, fb->pitch, fb->depth);
-
info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
info->fbops = &radeonfb_ops;
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index f22e7fe..aac27bd 100644
--- a/include/drm/drm_fb_helper.h
++
Re: glint KMS - how to proceed?
> Whoo! I'll put this up on k.org as soon as I can get it working. The only problem is it will not work with X running with the tdfx xorg driver :-( The driver will need more love as well. > ~ C. > > On Wed, Jul 14, 2010 at 12:01 PM, James Simmons > wrote: > > > >> On Wed, Jun 23, 2010 at 1:22 PM, Matt Turner wrote: > >> > On Wed, Jun 23, 2010 at 12:03 PM, James Simmons > >> > wrote: > >> >> > >> >>> I'm working on modesetting, and I'm kind of unsure how to proceed. > >> >>> > >> >>> My repository is here (ignore all the commit dates): > >> >>> http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary > >> >> > >> >> I also did one for the 3Dfx drm driver. Just as a note make sure that > >> >> your > >> >> glint driver works with the xorg driver. After I had a 3Dfx KMS driver > >> >> the > >> >> xorg driver no longer worked :-(. I would need to rework the xord driver > >> >> first then be able to submit my KMS driver. > >> > > >> > Is your 3dfx DRM driver available somewhere? It would be interesting to > >> > see. > >> > > >> > Thanks, > >> > Matt > >> > >> Ping? Can we see your driver? > > > > http://www.infradead.org/~jsimmons/tdfx.diff > > > > Sorry the driver bit rotted. I used modification to the dri core to > > get it > > going and be able to do real mode setting via the fbdev layer. Also the > > machine with a AGP bus I had no longer works. I need to get a new machine > > with a AGP bus that has some power behind it. This driver is updated but I > > doubt it will boot since I couldn't test it. > > The framebuffer management has much to desire since I couldn't > > find any good docs on TTM. So currently I'm using drm_addmap, yuck :-( > > Tho the posted driver has some ttm hooks in it. > > > > > > -- > > This SF.net email is sponsored by Sprint > > What will you do first with EVO, the first 4G phone? > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > -- > > ___ > > Dri-devel mailing list > > Dri-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > > -- > When the facts change, I change my mind. What do you do, sir? ~ Keynes > > Corbin Simpson > > -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glint KMS - how to proceed?
> On Wed, Jun 23, 2010 at 1:22 PM, Matt Turner wrote: > > On Wed, Jun 23, 2010 at 12:03 PM, James Simmons > > wrote: > >> > >>> I'm working on modesetting, and I'm kind of unsure how to proceed. > >>> > >>> My repository is here (ignore all the commit dates): > >>> http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary > >> > >> I also did one for the 3Dfx drm driver. Just as a note make sure that your > >> glint driver works with the xorg driver. After I had a 3Dfx KMS driver the > >> xorg driver no longer worked :-(. I would need to rework the xord driver > >> first then be able to submit my KMS driver. > > > > Is your 3dfx DRM driver available somewhere? It would be interesting to see. > > > > Thanks, > > Matt > > Ping? Can we see your driver? http://www.infradead.org/~jsimmons/tdfx.diff Sorry the driver bit rotted. I used modification to the dri core to get it going and be able to do real mode setting via the fbdev layer. Also the machine with a AGP bus I had no longer works. I need to get a new machine with a AGP bus that has some power behind it. This driver is updated but I doubt it will boot since I couldn't test it. The framebuffer management has much to desire since I couldn't find any good docs on TTM. So currently I'm using drm_addmap, yuck :-( Tho the posted driver has some ttm hooks in it. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glint KMS - how to proceed?
> I'm working on modesetting, and I'm kind of unsure how to proceed. > > My repository is here (ignore all the commit dates): > http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary I also did one for the 3Dfx drm driver. Just as a note make sure that your glint driver works with the xorg driver. After I had a 3Dfx KMS driver the xorg driver no longer worked :-(. I would need to rework the xord driver first then be able to submit my KMS driver. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] fb: fix colliding defines for fb flags.
> From: Dave Airlie
>
> When I added the flags I must have been using a 25 line terminal and missed
> the following flags.
>
> The collided with flag has one user in staging despite being in-tree for 5
> years.
>
> I'm happy to push this via my drm tree unless someone really wants to do it.
>
> Signed-off-by: Dave Airlie
> Cc: sta...@kernel.org
> ---
> include/linux/fb.h |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Signed-off-by: James Simmons
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 907ace3..8e5a9df 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -786,8 +786,6 @@ struct fb_tile_ops {
> #define FBINFO_MISC_USEREVENT 0x1 /* event request
> from userspace */
> #define FBINFO_MISC_TILEBLITTING 0x2 /* use tile blitting */
> -#define FBINFO_MISC_FIRMWARE 0x4 /* a replaceable firmware
> - inited framebuffer */
>
> /* A driver may set this flag to indicate that it does want a set_par to be
> * called every time when fbcon_switch is executed. The advantage is that
> with
> @@ -801,6 +799,8 @@ struct fb_tile_ops {
> */
> #define FBINFO_MISC_ALWAYS_SETPAR 0x4
>
> +/* where the fb is a firmware driver, and can be replaced with a proper one
> */
> +#define FBINFO_MISC_FIRMWARE0x8
> /*
> * Host and GPU endianness differ.
> */
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vt/console: try harder to print output when panicing
> From: Jesse Barnes
>
> Jesse's initial patch commit said:
>
> "At panic time (i.e. when oops_in_progress is set) we should try a bit
> harder to update the screen and make sure output gets to the VT, since
> some drivers are capable of flipping back to it.
>
> So make sure we try to unblank and update the display if called from a
> panic context."
>
> I've enhanced this to add a flag to the vc that console layer can set
> to indicate they want this behaviour to occur. This also adds support
> to fbcon for that flag and adds an fb flag for drivers to indicate
> they want to use the support. It enables this for KMS drivers.
>
> Signed-off-by: Dave Airlie
I really like the fact that the console driver has a flag to turn this on
or off.
Signed-off-by: James Simmons
> ---
> drivers/char/vt.c | 13 +
> drivers/gpu/drm/i915/intel_fb.c |4 +---
> drivers/gpu/drm/nouveau/nouveau_fbcon.c |1 +
> drivers/gpu/drm/radeon/radeon_fb.c |2 +-
> drivers/video/console/fbcon.c |4 +++-
> include/linux/console_struct.h |1 +
> include/linux/fb.h |4
> include/linux/vt_kern.h |7 +++
> 8 files changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/char/vt.c b/drivers/char/vt.c
> index 7cdb6ee..6e04c9e 100644
> --- a/drivers/char/vt.c
> +++ b/drivers/char/vt.c
> @@ -698,7 +698,10 @@ void redraw_screen(struct vc_data *vc, int is_switch)
> update_attr(vc);
> clear_buffer_attributes(vc);
> }
> - if (update && vc->vc_mode != KD_GRAPHICS)
> +
> + /* Forcibly update if we're panicing */
> + if ((update && vc->vc_mode != KD_GRAPHICS) ||
> + vt_force_oops_output(vc))
> do_update_region(vc, vc->vc_origin,
> vc->vc_screenbuf_size / 2);
> }
> set_cursor(vc);
> @@ -736,6 +739,7 @@ static void visual_init(struct vc_data *vc, int num, int
> init)
> vc->vc_hi_font_mask = 0;
> vc->vc_complement_mask = 0;
> vc->vc_can_do_color = 0;
> + vc->vc_panic_force_write = false;
> vc->vc_sw->con_init(vc, init);
> if (!vc->vc_complement_mask)
> vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800;
> @@ -2498,7 +2502,7 @@ static void vt_console_print(struct console *co, const
> char *b, unsigned count)
> goto quit;
> }
>
> - if (vc->vc_mode != KD_TEXT)
> + if (vc->vc_mode != KD_TEXT && !vt_force_oops_output(vc))
> goto quit;
>
> /* undraw cursor first */
> @@ -3703,7 +3707,8 @@ void do_unblank_screen(int leaving_gfx)
> return;
> }
> vc = vc_cons[fg_console].d;
> - if (vc->vc_mode != KD_TEXT)
> + /* Try to unblank in oops case too */
> + if (vc->vc_mode != KD_TEXT && !vt_force_oops_output(vc))
> return; /* but leave console_blanked != 0 */
>
> if (blankinterval) {
> @@ -3712,7 +3717,7 @@ void do_unblank_screen(int leaving_gfx)
> }
>
> console_blanked = 0;
> - if (vc->vc_sw->con_blank(vc, 0, leaving_gfx))
> + if (vc->vc_sw->con_blank(vc, 0, leaving_gfx) ||
> vt_force_oops_output(vc))
> /* Low-level driver cannot restore -> do it ourselves */
> update_screen(vc);
> if (console_blank_hook)
> diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
> index c3c5052..bd5d87a 100644
> --- a/drivers/gpu/drm/i915/intel_fb.c
> +++ b/drivers/gpu/drm/i915/intel_fb.c
> @@ -128,7 +128,7 @@ static int intelfb_create(struct intel_fbdev *ifbdev,
>
> strcpy(info->fix.id, "inteldrmfb");
>
> - info->flags = FBINFO_DEFAULT;
> + info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
> info->fbops = &intelfb_ops;
>
> /* setup aperture base/size for vesafb takeover */
> @@ -146,8 +146,6 @@ static int intelfb_create(struct intel_fbdev *ifbdev,
> info->fix.smem_start = dev->mode_config.fb_base + obj_priv->gtt_offset;
> info->fix.smem_len = size;
>
> - info->flags = FBINFO_DEFAULT;
> -
> info->screen_base = ioremap_wc(dev->agp->base + obj_priv->gtt_offset,
> size);
> if (!info->screen_base) {
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index c9a4a0d..9b2d3b7 100644
What happen to drm-fbdev1 branch?
Sorry I have been away. It looks like the drm-fbdev-fix branch has not been merged and it has been abandoned. I tested it on both my setups at home and it worked very well. Will this branch be merged or worked on more? -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] remove drm_fb_helper_setcolreg
This patch is against the drm-fbdevfix1 branch. It removes the
drm_fb_helper_setcolreg function. The reason is that fb_setcolreg is only
used in the case where fb_setcmap is called and no fb_ops->fb_setcmap is
used. In the drm case we always need a fb_setcmap hook to handle multiple
crtcs so we don't need a fb_setcolreg hook. Please apply.
Signed-off-by: James Simmons
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3757a25..64a207c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -594,36 +594,6 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct
fb_info *info)
}
EXPORT_SYMBOL(drm_fb_helper_setcmap);
-int drm_fb_helper_setcolreg(unsigned regno,
- unsigned red,
- unsigned green,
- unsigned blue,
- unsigned transp,
- struct fb_info *info)
-{
- struct drm_fb_helper *fb_helper = info->par;
- struct drm_crtc *crtc;
- struct drm_crtc_helper_funcs *crtc_funcs;
- int i;
- int ret;
-
- if (regno > 255)
- return 1;
-
- for (i = 0; i < fb_helper->crtc_count; i++) {
- crtc = fb_helper->crtc_info[i].mode_set.crtc;
- crtc_funcs = crtc->helper_private;
-
- ret = setcolreg(crtc, red, green, blue, regno, info);
- if (ret)
- return ret;
-
- crtc_funcs->load_lut(crtc);
- }
- return 0;
-}
-EXPORT_SYMBOL(drm_fb_helper_setcolreg);
-
int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index e722f42..2969df7 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -56,7 +56,6 @@ static struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
- .fb_setcolreg = drm_fb_helper_setcolreg,
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index d7cb238..39134e8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -98,7 +98,6 @@ static struct fb_ops nouveau_fbcon_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
- .fb_setcolreg = drm_fb_helper_setcolreg,
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
@@ -112,7 +111,6 @@ static struct fb_ops nv04_fbcon_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
- .fb_setcolreg = drm_fb_helper_setcolreg,
.fb_fillrect = nv04_fbcon_fillrect,
.fb_copyarea = nv04_fbcon_copyarea,
.fb_imageblit = nv04_fbcon_imageblit,
@@ -126,7 +124,6 @@ static struct fb_ops nv50_fbcon_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
- .fb_setcolreg = drm_fb_helper_setcolreg,
.fb_fillrect = nv50_fbcon_fillrect,
.fb_copyarea = nv50_fbcon_copyarea,
.fb_imageblit = nv50_fbcon_imageblit,
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index 79a6e6f..4cbc718 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -52,7 +52,6 @@ static struct fb_ops radeonfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
- .fb_setcolreg = drm_fb_helper_setcolreg,
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> > > > The fb_ops can only be called from fbcon or the fbdev userland > > > > interface. > > > > The fbcon calls should only happen when the VC is in KD_TEXT mode. Now > > > > with the DRM backend we have the advantage of creating a mapping > > > > seperate > > > > from the console mapping. A fb_open/fb_close could be used to cleaning > > > > up > > > > the userland mmap as well as handle the console pinning. We can supply > > > > your own fb_mmap hook. > > > > > > Again, the issue is not userspace but that fb_ops hooks can be called > > > from interrupt context etc. > > > > This should not happen. The VT layer is protected from calling in the > > interrupt context. TNor does fbcon call any fb_ops methods from a irq. > > E.g. printk? Sorry I have been sick. This is true when you are in KD_TEXT mode and using fbcon. Now while working on a graphical console yes you can have other hardware devices do a printk which can alter the state of of your graphics card. As for debugging a graphics driver you have to be very careful with your printks. Usually in that case I use two graphics cards in my system and map one to fbcon and test the other graphcis cards driver. P.S The fbdev api is such that it doesn't always require a permanent framebuffer mapping. This was done for the case of graphical hardware that lacks a directly accessable framebuffer. If you have accelerated fillrect,copyarea,and imageblit then you don't even the mapping except in the case of someone calling mmap on /dev/fbX. I noticed the nouveau drivers has a accelerated fbcon :-) -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> > The fb_ops can only be called from fbcon or the fbdev userland interface. > > The fbcon calls should only happen when the VC is in KD_TEXT mode. Now > > with the DRM backend we have the advantage of creating a mapping seperate > > from the console mapping. A fb_open/fb_close could be used to cleaning up > > the userland mmap as well as handle the console pinning. We can supply > > your own fb_mmap hook. > > Again, the issue is not userspace but that fb_ops hooks can be called > from interrupt context etc. This should not happen. The VT layer is protected from calling in the interrupt context. TNor does fbcon call any fb_ops methods from a irq. I have to look at the fbdev drivers but to my knowledge none touch any memory while in a context. Have you seen this happen before? Please let me know do I can fix it right a way. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> > The big issue we have with resizing the buffer is userspace mmaps of the > > fbdev > > device, and invalidation. > > Previous thread of unresolvedness is here. > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html > > Actually AFAIR (and reading through it again seems to confirm this) > userspace mappings should be fully handled by the last patch series I > posted back then[0]. The problem was that the struct fb_ops hooks may be > called by the kernel from pretty much any context, and neither I nor > Thomas was sure how to handle the TTM locking given that. Maybe James > has ideas for this given his better familiarity with fbdev internals. The fb_ops can only be called from fbcon or the fbdev userland interface. The fbcon calls should only happen when the VC is in KD_TEXT mode. Now with the DRM backend we have the advantage of creating a mapping seperate from the console mapping. A fb_open/fb_close could be used to cleaning up the userland mmap as well as handle the console pinning. We can supply your own fb_mmap hook. > [0] Though that was really only about making it possible to unpin the > fbcon BO while it isn't being displayed, resizing it might involve other > issues I'm not aware of. Yeap, but both problems are related. Kill two birds with one stone. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> > Searching the TTM code I couldn't find the handle code so easily. I see > > that the vmwgfx driver provides a example of using ttm. > > So handles are purely a userspace interface, in-kernel we don't use handles > for buffer management, the vmwgfx TTM interface has > vmw_user_surface_lookup_handle > to do the bo lookups. Yeap, some how userland has to tell which buffer is which. I also noticed their is a ttm_base_object_lookup which does the same thing :-) -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH v2] drm modes to fbdev mode patch
Here is the second version of the patch. It address the issues you brought
up.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5054970..0c8c756 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -581,6 +581,101 @@ int drm_fb_helper_setcolreg(unsigned regno,
}
EXPORT_SYMBOL(drm_fb_helper_setcolreg);
+void drm_display_mode_to_fbmode(struct drm_display_mode *mode,
+struct fb_videomode *fbmode)
+{
+ fbmode->xres = mode->hdisplay;
+ fbmode->yres = mode->vdisplay;
+ fbmode->right_margin = mode->hsync_start - mode->hdisplay;
+ fbmode->lower_margin = mode->vsync_start - mode->vdisplay;
+ fbmode->hsync_len = mode->hsync_end - mode->hsync_start;
+ fbmode->vsync_len = mode->vsync_end - mode->vsync_start;
+ fbmode->left_margin = mode->htotal - mode->hsync_end;
+ fbmode->upper_margin = mode->vtotal - mode->vsync_end;
+ fbmode->refresh = mode->vrefresh;
+
+ /* Doing a var to fb_videomode always create a proper pixclock
+* we can trust, but the reverse is not true. So we create
+* a proper pixclock from the refresh rate wanted. */
+ fbmode->pixclock = mode->vrefresh * mode->vtotal;
+ fbmode->pixclock *= mode->htotal;
+ fbmode->pixclock /= 1000;
+ fbmode->pixclock = KHZ2PICOS(fbmode->pixclock);
+
+ /* No mapping for sync on green or external sync from drm */
+ if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+ fbmode->vmode |= FB_SYNC_HOR_HIGH_ACT;
+
+ if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+ fbmode->vmode &= ~FB_SYNC_HOR_HIGH_ACT;
+
+ if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+ fbmode->vmode |= FB_SYNC_VERT_HIGH_ACT;
+
+ if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+ fbmode->vmode &= ~FB_SYNC_VERT_HIGH_ACT;
+
+ if (mode->flags & (DRM_MODE_FLAG_CSYNC | DRM_MODE_FLAG_PCSYNC |
+ DRM_MODE_FLAG_NCSYNC))
+ fbmode->vmode |= FB_SYNC_COMP_HIGH_ACT;
+
+ if (mode->flags & DRM_MODE_FLAG_BCAST)
+ fbmode->vmode |= FB_SYNC_BROADCAST;
+
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ if (!(mode->flags & DRM_MODE_FLAG_DBLSCAN))
+ fbmode->vmode |= FB_VMODE_INTERLACED;
+
+ if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ if (!(mode->flags & DRM_MODE_FLAG_INTERLACE))
+ fbmode->vmode |= FB_VMODE_INTERLACED;
+}
+EXPORT_SYMBOL(drm_display_mode_to_fbmode);
+
+/* No sync on green or external sync */
+void fbmode_to_drm_display_mode(struct fb_videomode *fbmode,
+struct drm_display_mode *mode)
+{
+ mode->hdisplay = fbmode->xres;
+ mode->vdisplay = fbmode->yres;
+ mode->hsync_start = mode->hdisplay + fbmode->right_margin;
+ mode->vsync_start = mode->vdisplay + fbmode->lower_margin;
+ mode->hsync_end = mode->hsync_start + fbmode->hsync_len;
+ mode->vsync_end = mode->vsync_start + fbmode->vsync_len;
+ mode->htotal = mode->hsync_end + fbmode->left_margin;
+ mode->vtotal = mode->vsync_end + fbmode->upper_margin;
+ mode->vrefresh = fbmode->refresh;
+ mode->clock = PICOS2KHZ(fbmode->pixclock);
+
+ /* No mapping for sync on green or external sync to drm */
+ if (fbmode->vmode & FB_SYNC_HOR_HIGH_ACT)
+ mode->flags |= DRM_MODE_FLAG_PHSYNC;
+ else
+ mode->flags |= DRM_MODE_FLAG_NHSYNC;
+
+ if (fbmode->vmode & FB_SYNC_VERT_HIGH_ACT)
+ mode->flags |= DRM_MODE_FLAG_PVSYNC;
+ else
+ mode->flags |= DRM_MODE_FLAG_NVSYNC;
+
+ if (fbmode->vmode & FB_SYNC_COMP_HIGH_ACT)
+ mode->flags |= DRM_MODE_FLAG_CSYNC;
+
+ if (fbmode->vmode & FB_SYNC_BROADCAST)
+ mode->flags |= DRM_MODE_FLAG_BCAST;
+
+ if ((fbmode->vmode & FB_VMODE_MASK) == FB_VMODE_INTERLACED)
+ if (!((fbmode->vmode & FB_VMODE_MASK) == FB_VMODE_DOUBLE))
+ mode->flags |= DRM_MODE_FLAG_INTERLACE;
+
+ if ((fbmode->vmode & FB_VMODE_MASK) == FB_VMODE_DOUBLE)
+ if (!((fbmode->vmode & FB_VMODE_MASK) == FB_VMODE_INTERLACED))
+ mode->flags |= DRM_MODE_FLAG_DBLSCAN;
+
+ drm_mode_set_name(mode);
+}
+EXPORT_SYMBOL(fbmode_to_drm_display_mode);
+
int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
@@ -762,6 +857,7 @@ int drm_fb_helper_single_fb_probe(struct drm_device *dev,
int crtc_count = 0;
int ret, i, conn_count = 0;
struct fb_info *info;
+ struct fb_videomode fbmode;
struct drm_framebuffer *fb;
struct drm_mode_set *modeset = NULL;
struct drm_fb_helper *fb_helper;
@@ -780,7 +876,7 @@ int drm_fb_helper_single_fb_probe(struct drm_device *dev,
if (!fb_help_conn)
Re: [PATCH] drm modes to fbdev mode patch
> > For the fbdev layer the you have your struct fb_var_screeninfo and also
> > struct fb_videomode. The struct fb_videomode was developed for the modes
> > database we have. Struct fb_var_screeninfo is more than just resolution
> > data which is why we create struct fb_videomode. The really nice thing
> > is that the conversion from fb_var to fb_videomode always fixes the
> > pixclock to the proper values so you don't need the pixclock = 0 work
> > around. I tested this patch with the intelfb driver and had no problem.
> > I have used it in the past with a KMS enabled tdfx drver I wrote. In the
> > future this function can be used for fbdev level mode setting. Please try
> > it out and i hope it can be merged. Thanks.
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 5054970..467ac68 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -581,6 +581,60 @@ int drm_fb_helper_setcolreg(unsigned regno,
> > }
> > EXPORT_SYMBOL(drm_fb_helper_setcolreg);
> >
> > +void drm_display_mode_to_fbmode(struct drm_display_mode *mode,
> > +struct fb_videomode *fbmode)
> > +{
> > + fbmode->xres = mode->hdisplay;
> > + fbmode->yres = mode->vdisplay;
> > + fbmode->right_margin = mode->hsync_start - mode->hdisplay;
> > + fbmode->lower_margin = mode->vsync_start - mode->vdisplay;
> > + fbmode->hsync_len = mode->hsync_end - mode->hsync_start;
> > + fbmode->vsync_len = mode->vsync_end - mode->vsync_start;
> > + fbmode->left_margin = mode->htotal - mode->hsync_end;
> > + fbmode->upper_margin = mode->vtotal - mode->vsync_end;
> > + fbmode->refresh = mode->vrefresh;
> > + fbmode->name = mode->name;
>
> Is there some guarantee that mode won't be freed before fbmode? That
> would leave fbmode->name pointing to invalid memory.
Ah. The fbdev layer doesn't alloc memory for this string. Will fix.
> > +
> > + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > + fbmode->vmode |= FB_VMODE_INTERLACED;
> > +
> > + if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > + fbmode->vmode |= FB_VMODE_DOUBLE;
> > +
>
> What about the sync flags?
Haven't got around to it yet. Plus some flags don't map so well.
> > + mode->vrefresh = fbmode->refresh;
> > + mode->clock = PICOS2KHZ(fbmode->pixclock);
> > +
> > + if ((fbmode->vmode & FB_VMODE_MASK) == FB_VMODE_INTERLACED)
> > + mode->flags |= DRM_MODE_FLAG_INTERLACE;
> > +
> > + if ((fbmode->vmode & FB_VMODE_MASK) == FB_VMODE_DOUBLE)
> > + mode->flags |= DRM_MODE_FLAG_DBLSCAN;
>
> Is interlaced+dblscan considered an invalid combination? The conversion
> to the other direction didn't make that assumption.
True they tend to cancel each other out. I can work on that as well.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm modes to fbdev mode patch
For the fbdev layer the you have your struct fb_var_screeninfo and also
struct fb_videomode. The struct fb_videomode was developed for the modes
database we have. Struct fb_var_screeninfo is more than just resolution
data which is why we create struct fb_videomode. The really nice thing
is that the conversion from fb_var to fb_videomode always fixes the
pixclock to the proper values so you don't need the pixclock = 0 work
around. I tested this patch with the intelfb driver and had no problem.
I have used it in the past with a KMS enabled tdfx drver I wrote. In the
future this function can be used for fbdev level mode setting. Please try
it out and i hope it can be merged. Thanks.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5054970..467ac68 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -581,6 +581,60 @@ int drm_fb_helper_setcolreg(unsigned regno,
}
EXPORT_SYMBOL(drm_fb_helper_setcolreg);
+void drm_display_mode_to_fbmode(struct drm_display_mode *mode,
+struct fb_videomode *fbmode)
+{
+ fbmode->xres = mode->hdisplay;
+ fbmode->yres = mode->vdisplay;
+ fbmode->right_margin = mode->hsync_start - mode->hdisplay;
+ fbmode->lower_margin = mode->vsync_start - mode->vdisplay;
+ fbmode->hsync_len = mode->hsync_end - mode->hsync_start;
+ fbmode->vsync_len = mode->vsync_end - mode->vsync_start;
+ fbmode->left_margin = mode->htotal - mode->hsync_end;
+ fbmode->upper_margin = mode->vtotal - mode->vsync_end;
+ fbmode->refresh = mode->vrefresh;
+ fbmode->name = mode->name;
+
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ fbmode->vmode |= FB_VMODE_INTERLACED;
+
+ if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ fbmode->vmode |= FB_VMODE_DOUBLE;
+
+ /* Doing a var to fb_videomode always create a proper pixclock
+* we can trust, but the reverse is not true. So we create
+* a proper pixclock from the refresh rate wanted. */
+ fbmode->pixclock = mode->vrefresh * mode->vtotal;
+ fbmode->pixclock *= mode->htotal;
+ fbmode->pixclock /= 1000;
+ fbmode->pixclock = KHZ2PICOS(fbmode->pixclock);
+}
+EXPORT_SYMBOL(drm_display_mode_to_fbmode);
+
+void fbmode_to_drm_display_mode(struct fb_videomode *fbmode,
+struct drm_display_mode *mode)
+{
+ mode->hdisplay = fbmode->xres;
+ mode->vdisplay = fbmode->yres;
+ mode->hsync_start = mode->hdisplay + fbmode->right_margin;
+ mode->vsync_start = mode->vdisplay + fbmode->lower_margin;
+ mode->hsync_end = mode->hsync_start + fbmode->hsync_len;
+ mode->vsync_end = mode->vsync_start + fbmode->vsync_len;
+ mode->htotal = mode->hsync_end + fbmode->left_margin;
+ mode->vtotal = mode->vsync_end + fbmode->upper_margin;
+ mode->vrefresh = fbmode->refresh;
+ mode->clock = PICOS2KHZ(fbmode->pixclock);
+
+ if ((fbmode->vmode & FB_VMODE_MASK) == FB_VMODE_INTERLACED)
+ mode->flags |= DRM_MODE_FLAG_INTERLACE;
+
+ if ((fbmode->vmode & FB_VMODE_MASK) == FB_VMODE_DOUBLE)
+ mode->flags |= DRM_MODE_FLAG_DBLSCAN;
+
+ drm_mode_set_name(mode);
+}
+EXPORT_SYMBOL(fbmode_to_drm_display_mode);
+
int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
@@ -762,6 +816,7 @@ int drm_fb_helper_single_fb_probe(struct drm_device *dev,
int crtc_count = 0;
int ret, i, conn_count = 0;
struct fb_info *info;
+ struct fb_videomode fbmode;
struct drm_framebuffer *fb;
struct drm_mode_set *modeset = NULL;
struct drm_fb_helper *fb_helper;
@@ -891,8 +946,11 @@ int drm_fb_helper_single_fb_probe(struct drm_device *dev,
fb_helper->crtc_count = crtc_count;
fb_helper->fb = fb;
+ /* Convert from drm mode to fb_var_screeninfo */
+ drm_display_mode_to_fbmode(modeset->mode, &fbmode);
+ fb_videomode_to_var(&info->var, &fbmode);
+
if (new_fb) {
- info->var.pixclock = 0;
ret = fb_alloc_cmap(&info->cmap, modeset->crtc->gamma_size, 0);
if (ret)
return ret;
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 58c892a..29fdb01 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -99,6 +99,10 @@ int drm_fb_helper_setcolreg(unsigned regno,
struct fb_info *info);
void drm_fb_helper_restore(void);
+void drm_display_mode_to_fbmode(struct drm_display_mode *mode,
+ struct fb_videomode *fbmode);
+void fbmode_to_drm_display_mode(struct fb_videomode *fbmode,
+ struct drm_display_mode *mode);
void drm_fb_helper_fill_var(struct fb_info *info, struct drm_framebuffer *fb,
uint32_t fb_width
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> >> Can't it print the oops on whatever is currently displayed? > >> > >> It need not be a dedicated buffer as long as there is always some buffer. > >> > >> But perhaps this is more complex than that. > > > > Yes it is very complex. Reading the code and drm specs you come to > > realize buffer handling is done with GEM, TTM, or for older drivers > > drm_maps. > > Drivers often handle a combine of those, meaning no real wrapper from one > > api to another :-( From the code it appears GEM is the main userland > > interface > > when using KMS. Some how TTM is also usable from userland but I never found > > a > > clear example of how that is done. So to the average userland app writer it > > is > > a mystery. As for hardware that has a static front buffer I can see how to > > use drm_maps or TTM but I don't see a easy way to map it to the GEM api. > > Also their exist ioctl for gem but it appears no one actually uses them > > but instead write their own :-( So you can see the confusion here. > > Userspace buffer management interfaces are pre-driver, the only requirement > if that they have a 32-bit handle to identify buffers uniquely. Pre-KMS > drivers > don't exist for the purposes of fb interaction, so drm_maps are ignorable from > that pov. > > Outside of what I described above the drm_framebuffer handling is > > a mess. From what I can see with the code you can only create a > > drm_framebuffer with the GEM api. With this case the two most important > > functions to provide are > > This isn't correct. You get a drm_file and a handle, the driver then uses > these to do whatever it wants to do. This means lookup a GEM object or > whatever but there is no reliance on GEM or any other memory manager > outside the driver. Again a handle a file priv are in no way GEM specific. Searching the TTM code I couldn't find the handle code so easily. I see that the vmwgfx driver provides a example of using ttm. > > This gets me to point of where to go from here. We have two choices. > > The first being we could just make the drm_framebuffer code totally gem > > dependent thus we could cleanup the drivers code up by moving gem code > > there. The second option is to make the drm_framebuffer code agnostic to > > the gem > > layer. So I have been pondering on how to make the second option work. > > There is one thing that all these layers do share in common. That is they > > have some sort of drm_hash with a object lookup. Still pondering how that > > would be done. > > I'm not sure either of these makes sense, can you clearly state the > goal and maybe we can work out what you need. Sorry I should of stated what I was planing to do. I like to see drmfb have the ablitiy to change the resolution via fbset. To do that we need to be able to create and destory the framebuffer memory if the memory doesn't fit the size of the new resolution. Plus it gives us the bonus of being able to unpin the memory when the VT is in KD_GRAPHICS mode. The problem is that the functions like fb_create are tied to a handle which is not present for the internal framebuffer used by fbdev. Sorry for the junk above. It just took me awhile to figure out the code. Their is steep learning curve. I have patches that should address this coming soon. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Thu, 11 Mar 2010, Michal Suchanek wrote: > On 11 March 2010 16:17, James Simmons wrote: > > > >> >> It would be nice to find a way to reclaim the console memory for X, > >> >> but I'm not sure that can be done and still provide a good way to > >> >> provide oops support. > >> > > >> > What do you think the average user will care about more? > >> > > >> > * Seeing kernel oops/panic output about once in a lifetime. > >> > * Being able to start/use X in the first place and enabling it to > >> > use all of VRAM. > >> > > >> > Personally, I've never even seen any kernel oops/panic output despite > >> > numerous opportunities for that in the couple of months I've been using > >> > KMS. But I have spent considerable time and effort trying to get rid of > >> > the pinned fbcon BO. If the oops/panic output is the only thing > >> > preventing that, maybe that should only be enabled via some module > >> > option for developers. > >> > >> I'm all for it! > > > > I'm looking into the details for this. It will require some changes to > > internal apis to make it to work. > > > > Can't it print the oops on whatever is currently displayed? > > It need not be a dedicated buffer as long as there is always some buffer. > > But perhaps this is more complex than that. Yes it is very complex. Reading the code and drm specs you come to realize buffer handling is done with GEM, TTM, or for older drivers drm_maps. Drivers often handle a combine of those, meaning no real wrapper from one api to another :-( From the code it appears GEM is the main userland interface when using KMS. Some how TTM is also usable from userland but I never found a clear example of how that is done. So to the average userland app writer it is a mystery. As for hardware that has a static front buffer I can see how to use drm_maps or TTM but I don't see a easy way to map it to the GEM api. Also their exist ioctl for gem but it appears no one actually uses them but instead write their own :-( So you can see the confusion here. Outside of what I described above the drm_framebuffer handling is a mess. From what I can see with the code you can only create a drm_framebuffer with the GEM api. With this case the two most important functions to provide are dev->mode_config.funcs->fb_create(dev, file_priv, r) and fb->funcs->create_handle(fb, file_priv, &r->handle); As you can see if the functions they depend on a handle and a drm_file. To make it possible to create a framebuffer internally using a common code we would remove those requirements. This gets me to point of where to go from here. We have two choices. The first being we could just make the drm_framebuffer code totally gem dependent thus we could cleanup the drivers code up by moving gem code there. The second option is to make the drm_framebuffer code agnostic to the gem layer. So I have been pondering on how to make the second option work. There is one thing that all these layers do share in common. That is they have some sort of drm_hash with a object lookup. Still pondering how that would be done.-- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> >> It would be nice to find a way to reclaim the console memory for X, > >> but I'm not sure that can be done and still provide a good way to > >> provide oops support. > > > > What do you think the average user will care about more? > > > > * Seeing kernel oops/panic output about once in a lifetime. > > * Being able to start/use X in the first place and enabling it to > > use all of VRAM. > > > > Personally, I've never even seen any kernel oops/panic output despite > > numerous opportunities for that in the couple of months I've been using > > KMS. But I have spent considerable time and effort trying to get rid of > > the pinned fbcon BO. If the oops/panic output is the only thing > > preventing that, maybe that should only be enabled via some module > > option for developers. > > I'm all for it! I'm looking into the details for this. It will require some changes to internal apis to make it to work. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
My goal
Okay all the discussion about multiple display brings me to why I'm doing this. I'm attempting to revive the linux console project. I'm in a position to again work on this project. About 4 years ago the eproject managed to get multi-seat working. My goal is to get there again. My first goal is to get my netbook to act has a multiseat system for two. With a plugged in external montior and a USB keyboard run two concurrent X sessions both running OpenGL applications at the same time. I set out to do this 10 years ago and I want to finally accomplish this. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> > Yuck. See my other post about what fbdev really means in its historical > > context. The struct fb_info really maps better to drm_crtc than to > > drm_framebuffer. In fact take the case of the matrox fbdev driver. It > > creates two framebuffer devices even tho it used one static framebuffer. > > What the driver does is splits the framebuffer in two and assigned each > > part to a CRTC. > > > > So you get the layering naturally. On fbset - fbev layer you can > choose from the resolutions available in the current output setup, in > kmset or whatever - drm layer you can set up the outputs, merge > multiple outputs into single cloned fbdev or separate them, .. > > It's obviously nice if you can set the resolution on all of fbcons, > fbdev and drm layers but getting it work on at least one layer with > proper propagation up and down also works. BTW I don't know any > application which sets linux console (or xterm for that matter) > resolution through the terminal API. I agree. The mode setting should be done in one layer. Its a matter of doing the proper emulation of the fbdev layer. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> > I don't think the CRTC=fb_info makes much sense if the main use > > case is fbcon. fbcon will use a single fb device and so you can't see > > the console on multiple heads anyway which makes the whole thing > > somewhat pointless. And if you're trying to do something more complex > > you will be a lot better off bypassing fbdev altogether. > > > > I guess it's also possible that somebody would want the fbdev/fbcons > cover multiple screens. This is not particularly useful with fbcons > (although curses WMs exist) but might be somewhat useful for graphical > fbdev applications. I really can't see fbcon need that. > Multiple views of the kernel virtual consoles on different heads might > be nice toy but it's probably too hard to be worth trying. And there > are always applications like jfbterm which could be perhaps slightly > adapted to use one of the other devices instead of a vc. It already exist. I guess it is one of those best kept secrets. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> > > There are other drivers that support multihead already (matroxfb, any > > > other?) and have their own driver-specific inteface. > > > > Each crtc is treated as a seperate fbdev device. I don't recall any > > special ioctls. Maybe for mirroring which was never standardized. > > matroxfb does have a bunch of custom ioctls to change the crtc<->output > mapping. Yes the mapping issue were never address. > I don't think the CRTC=fb_info makes much sense if the main use > case is fbcon. Actually that is what I had in mind when I reworked the fbdev api. Plus with the linux console project I got multiple VTs working at the same time. > fbcon will use a single fb device and so you can't see > the console on multiple heads anyway which makes the whole thing > somewhat pointless. And if you're trying to do something more complex > you will be a lot better off bypassing fbdev altogether. Not true. You can map different displays to different vcs. Give con2fb a try some time :-) Now there is the issue of more than one keyboard being mapped at a time. BTW I did getting multipe VT working at the same time working in the past. It requires some cleanup on the console layer. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> >> Yuck. See my other post about what fbdev really means in its historical > >> context. The struct fb_info really maps better to drm_crtc than to > >> drm_framebuffer. In fact take the case of the matrox fbdev driver. It > >> creates two framebuffer devices even tho it used one static framebuffer. > >> What the driver does is splits the framebuffer in two and assigned each > >> part to a CRTC. > > > > The only problem with that is that it eats a lot of memory for the > > console which limits X when it starts. On cards with limited vram , > > you might not have enough memory left for any meaningful acceleration > > when X starts. > > It would be nice to find a way to reclaim the console memory for X, > but I'm not sure that can be done and still provide a good way to > provide oops support. Ah, the power of flags. We had the same issue with user requesting a mode change or fbcon asking for a different mode. We handled it with the flag FBINFO_MISC_USEREVENT. Since you are using KMS as the backend for fbcon you will have to deal also with the ability to change the resolution with tools like stty. I can easily see how to do this plus give you more memory like you want :-) For the oops are you talking about printing oops to the screen while X is running ? Otherwise if you experience a oops and go back to console mode you should be able to view it. The console text buffer is independent of the graphics card memory system. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> I don't think so. There is another driver which does this - > vesa/uvesa. For these it is not possible to change the resolution from > fbdev, it just provides some framebuffer on top of which fb > applications or fbcons run. Only because that is the only way to do it. The other options was to have x86emul in the kernel. That was not going to happen. > I guess equivalent of xrandr would be what people would want but the > current fbdev capabilities are far from that. > Since KMS provides these capabilities already I would think adding a > tool that manipulates KMS directly (kmset?) is the simplest way. Still would have to deal with the issue of keeping the graphical console in sync with the changes. > There are other drivers that support multihead already (matroxfb, any > other?) and have their own driver-specific inteface. Each crtc is treated as a seperate fbdev device. I don't recall any special ioctls. Maybe for mirroring which was never standardized. > Designing an unified multihead fbdev extension interface would > probably take quite a bit of typing and time. It would also help to > have something working to compare to. IMNSHO the fbdev to ctrc mapping should be the standard way to handle the fbdev layer. Plus it is a KISS approach. Mirroring would need to be finally dealt with. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> My main problem with calling the drm underneath the fbdev is it > seems like a layering violation. Then again some of code in the kernel > is also contributing to this violation. I'd really like to make fbdev more > like an in-kernel version of what X driver have to do, and leave all the > initial modepicking etc to the fbdev interface layer. > > If we take the layering as > fbcon -> fbdev -> kms -> hw > > I feel calling ioctls on the KMS layer from userspace to do stuff for > fbcon or fbdev > is wrong, and we should rather expose a more intelligent set of ioctls via the > fbdev device node. This points at quite a bit of typing. I agree. We had the same issue with fbdev and fbcon. From the fbcon layer you can call stty to change the resolution. In that case the mode change came from fbcon to fbdev. Easy problem to handle. Well some people still wanted to be able to able to change their console resolution with fbset. Not only change the resolution on one VC (virtual consoel) but in some cases change the resolution on all the VCs mapped to that fbdev. Now some times the user wanted to change the resolution for say a game (using SDL for example) and then expected the fbcon resolution to be restored when they exited. In that case we wanted the resolution change not to be propagated up to the fbcon layer. The way the fbdev changes are propagated with a notifier chain. Now the issue of mirroring is another thing which was never settled on. Considering now the KMS layer is not so bad as it seems. The fbdev emulation layer already changes the drm mode (fbdev -> kms) plus in that case you get the benefit of automatically sending a signal to the fbcon layer to keep it in sync. In the case of kms -> fbdev you need to update the fbdev state. This could be done pretty easily plus if done right would update the fbcon state as well. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> >> At the moment the problem with fbset is what to do with it in the > >> dual head case. Currently we create an fb console that is lowest > >> common size of the two heads and set native modes on both, > > > > Does that mean that fbset is supposed to work (set resolution) on drmfb? > > No we've never hooked it up but it could be made work. I had it to the point of almost working. I plan on working on getting it working again. > > Schemes which would make a multihead setup look like a single screen > > get complicated quite easily. Perhaps an option to turn off some > > outputs so that the native resolution of one output is used (instead > > of clone) would work. > > > > I've only really got two answer for this: > > (a) hook up another /dev/dri/card_fb device and use the current KMS > ioctls to control the framebuffer, have the drm callback into fbdev/fbcon > to mention resizes etc. Or add one or two info gathering ioctls and > allow use of the /dev/dri/control device to control stuff. > > (b) add a lot of ioctls to KMS fbdev device, which implement some sort > of sane multi-output settings. > > Now the second sounds like a lot of work if not the correct solution, > you basically needs a way to pretty much expose what the KMS ioctls > expose on the fb device, and then upgrade fbset to make sense of it all. Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> On 21 November 2009 05:27, Dave Airlie wrote: > > > At the moment the problem with fbset is what to do with it in the > > dual head case. Currently we create an fb console that is lowest > > common size of the two heads and set native modes on both, > > Does that mean that fbset is supposed to work (set resolution) on drmfb? Yes it could work. No it doesn't work. > > > > Now if a user runs fbset, I'm not sure what the right answer is, > > a) pick a head in advance via sysfs maybe and set it on that. > > b) try and set the mode on both heads cloned (what to do if > > there is no common mode is another issue). > > > > I would say it's time to support multihead with fbset properly. > > That is people would need new fbset which sees both (all) heads, and > fbset can then choose the head itself (and people can make it do > something different when they don't like the default). It should also > support setting up rotation on each head. > > For old fbset setting something visible is probably good enough. > > Schemes which would make a multihead setup look like a single screen > get complicated quite easily. Perhaps an option to turn off some > outputs so that the native resolution of one output is used (instead > of clone) would work. Before we go there you have to reflect on what the original reason was to have a framebuffer layer. The point to have a VT console terminal on platforms that lacked hardware that supported native text mode hardware. In other words had no vga text mode. A VT terminal is just a keyboard and a display. In fact in the old days you had to write framebuffer console drivers with things like con_putcs, con_write. Then the api was changed to make driver writing simple. The struct fb_info represented your graphics card. Of course at that time we also had hardware that supported more than one crtc which made things more complex. This was reflected in the new api. Struct fb_info was moved in the direction to represent the display. Remember the terminal only really cares about the display. Inside struct fb_info we have a void *par that was a pointer to some structure that represented the graphics card itself. So in the case of multi-head systems you could have two struct fb_info and one shared *par. That way if you wanted to changed the resolution on one screen the check_var function could using the *par to test if the hardware could support both resolutions at the same time. Note also there is exist a sysfs that allows you to migrate your second fbdev devices to a new terminal. Also problems exist in the upper console layers that prohibit true multi-desktop systems. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Move lists to freedesktop.org?
> Would anyone have objections if these lists moved to freedesktop.org? > The recent thread with Linus about the drm pull request highlights the > post lag and non-subscriber aspect of the current lists, and that > leaves aside sf.net's horrible mail archive interface and poor > performance. > > If spam is an issue, another option would be vger.kernel.org. That > team runs lkml and several other very high traffic, high profile lists > and manages quite well; performance is always high and spam is nearly > non-existent given the amount of traffic. Just wanted to bring up the experince of moving linux-fbdev from sf.net to vger. The reason we did the move was because of the amount of spam we had to deal with. Now we have no spam. Of course the draw back is that the old list still exist which means the spam still comes in thus it has to be dealt with. Not too big of a deal. The real issue is people still join the old mailing list and try to post there. Perhaps their is a way to forward subscriptions or send a message to the subscriber to tell them where to really join? Then you have to send real mail to the new list. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
> > > Second, in the KMS case, we'd be able to skip the kernel VT switch, > > > because > > > the KMS driver uses its own framebuffer anyway. > > > > > > So, is there any reasonable way to check that from the outside of the > > > graphics > > > driver? It should be general enough to cover the cases when there are two > > > graphics adapters with different drivers in the system and so forth. > > > > Inside the kernel? If you have a struct pci_dev you can get the > > associated struct drm_device with pci_get_drvdata and then check the > > KMS feature: drm_core_check_feature(dev, DRIVER_MODESET). > > Yeah, I know that. > > > I'm note sure how to check that a device is graphic card though :| > > Well, that's the "outside of the graphics driver" part of my question. :-) if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage4 crashes
> i've tried to run this old X server with new (2.6.32) kernel > > here is log from startup : > > http://83.18.229.190/Xorg/Xorg.0.log.old_X_new_kernel > > what is stunning - DRI works , and i get stunning 360fps > with gears turning _smoothly_ in glxgears. > > downsides - switching to VT doesn't work. > one can switch, keyboard works, but there is mess displayed > (white screen or remains of past console). > one can still type and execute commands (but nothing is displayed) Are you using the savage fbdev driver or vga console? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: fix regression in fb blank handling
> On Thu, 2010-01-21 at 09:09 +0800, Zhenyu Wang wrote: > > On 2010.01.20 13:14:23 +0000, James Simmons wrote: > > > > > > It's just adding the backlight api to the intel driver. In fact it gives > > > the user the ablity to control the brightness of the backlight which I > > > see > > > is lacking in the intel driver. > > > > Wait, this regression has nothing to do with backlight control. We already > > have backlight drivers for platform specific or ACPI interface, the reason > > intel driver doesn't hook up one is because if we provide native interface > > which would be much possible to have state conflict with platform or ACPI > > way. > > > > This problem is just the wrong DPMS state is used for FB blank request. > > Dave, does my patch look sane? This regression isn't in 2.6.32, but only > > for .33-rc kernel. > > We should revisit this for 2.6.34, but for now I've applied Zhenyu's > patch until we can figure out where the problems are, as it breaks a few > too many laptops at this stage for 2.6.33. I agree at this point. I need to get the hardware to test the changes. BTW is the GMA 950 supported by the i915 driver? I will pick up a net book in the next few days. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: fix regression in fb blank handling
> On 2010.01.19 16:17:56 +0000, James Simmons wrote: > > Sorry I meant the backlight power management state seperate from the > > encoder state. > > > > > drm_fb_helper_off() will find fb's crtc and attached encoders, then > > > call encoder_funcs->dpms() and turn off crtc, so for your DRM_MODE_DPMS_ON > > > change, it will actually turn encoder on, but what we need for > > > FB_BLANK_NORMAL is to turn off the display. No? > > > > FB_BLANK_NORMAL is not a full power down. Only CRTC is powerdown in this > > mode. > > So how the encoder could tell the meaning of you passed DRM_MODE_DPMS_ON in > this case? which is really turning on everything, or keep port on but turn > off panel power? So you are saying that certian combos of crtc dpms states and encoder dpms states are not possible. Since this can from a user application I assume the DRI layer has to fix this up. > > FB_BLANK_POWERDOWN turns off everything. You are wondering why this > > is the case. If the console blanks and you go to use it again it comes > > back very fast. In FB_BLANK_POWERDOWN mode it takes awhile to come back > > for certain types of displays. I have a old Sony CRT at home. Once powered > > down it takes about 5 to 10 seconds to come back up. > > Isn't this monitor specific issue instead of display device problem? ;) > I don't think any LCD monitor nowadays could have this issue. Don't forget about embedded devices. They can behave in the same way. > > Besides this the real issue is backlight != part of encoder. > > > > A patch will be coming shortly. > > Panel power sequencing for Intel LVDS is controlled by encoder, and closely > related to port state, although we haven't really taken LVDS port > enable/disable > step before Ironlake, I think this is normal case for encoders having > backlight. For non embedded platforms yes. Actually I worked on a embedded platform that used a SiS graphics chip. That chipset also has a backlight for the encoder but the manufacture instead disabled that backlight and instead used a external backlight powered by a external gpio. > Could we just restore back to origin behavior for fixing this in 2.6.33? > Otherwise I don't know if your patch would be too intrusive... It's just adding the backlight api to the intel driver. In fact it gives the user the ablity to control the brightness of the backlight which I see is lacking in the intel driver. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Font selection with i915
> When Fedora 12 loads i915 during initramfs probing on my system, the > driver automatically installs a tiny 160x64 font. How can I prevent it > from doing this, or tell it to use a larger 80x25 font instead? > > Is this documented anywhere? Not really. Here is how you enable larger fonts. Configure your kernel. Go into the Graphics support menu. This the the menu that has the DRI/Framebuffer and backlight options. You will see a "Console display driver support" option. Select it and you will have a new menu. You will see the option "Select compiled-in fonts". Enable that and select the font you want. Most likely it will be the Sun 12x22 font. Build your kernel. Their might be one more setup to do. Some distros like to load a console font at boot up. Depending on the distro if that is the case you will have to disable it. > In addition, are the error messages in the following dmesg log anything > to be concerned about? They appear during every boot: > > > [drm] Initialized drm 1.1.0 20060810 > i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > i915 :00:02.0: setting latency timer to 64 > fbcon: inteldrmfb (fb0) is primary device > render error detected, EIR: 0x0010 > [drm:i915_handle_error] *ERROR* EIR stuck: 0x0010, masking > render error detected, EIR: 0x0010 > [drm] DAC-5: set mode 1280x1024 16 > Console: switching to colour frame buffer device 160x64 > fb0: inteldrmfb frame buffer device > registered panic notifier > [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 No idea here. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: fix regression in fb blank handling
> > > uses DRM_MODE_DPMS_ON for FB_BLANK_NORMAL, but DRM_MODE_DPMS_ON > > > is actually for turning output on instead of blank. > > > > > > This makes fb blank broken on my T61, it put LVDS on but leave > > > pipe disabled which made screen totally white or caused some > > > 'burning' effect. > > > > > > Cc: James Simmons > > > Signed-off-by: Zhenyu Wang > > > --- > > > drivers/gpu/drm/drm_fb_helper.c |2 +- > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c > > > b/drivers/gpu/drm/drm_fb_helper.c > > > index 1c2b7d4..0f9e905 100644 > > > --- a/drivers/gpu/drm/drm_fb_helper.c > > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > > @@ -389,7 +389,7 @@ int drm_fb_helper_blank(int blank, struct fb_info > > > *info) > > > break; > > > /* Display: Off; HSync: On, VSync: On */ > > > case FB_BLANK_NORMAL: > > > - drm_fb_helper_off(info, DRM_MODE_DPMS_ON); > > > + drm_fb_helper_off(info, DRM_MODE_DPMS_STANDBY); > > > break; > > > /* Display: Off; HSync: Off, VSync: On */ > > > case FB_BLANK_HSYNC_SUSPEND: > > > > Nak. The problem is the intel drm drivers doesn't handle it power > > management state seperate from the encoder state. Sorry I meant the backlight power management state seperate from the encoder state. > drm_fb_helper_off() will find fb's crtc and attached encoders, then > call encoder_funcs->dpms() and turn off crtc, so for your DRM_MODE_DPMS_ON > change, it will actually turn encoder on, but what we need for > FB_BLANK_NORMAL is to turn off the display. No? FB_BLANK_NORMAL is not a full power down. Only CRTC is powerdown in this mode. FB_BLANK_POWERDOWN turns off everything. You are wondering why this is the case. If the console blanks and you go to use it again it comes back very fast. In FB_BLANK_POWERDOWN mode it takes awhile to come back for certain types of displays. I have a old Sony CRT at home. Once powered down it takes about 5 to 10 seconds to come back up. Besides this the real issue is backlight != part of encoder. A patch will be coming shortly. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: fix regression in fb blank handling
> commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e > Author: James Simmons > Date: Thu Oct 29 20:39:07 2009 + > > drm/kms: properly handle fbdev blanking > > uses DRM_MODE_DPMS_ON for FB_BLANK_NORMAL, but DRM_MODE_DPMS_ON > is actually for turning output on instead of blank. > > This makes fb blank broken on my T61, it put LVDS on but leave > pipe disabled which made screen totally white or caused some > 'burning' effect. > > Cc: James Simmons > Signed-off-by: Zhenyu Wang > --- > drivers/gpu/drm/drm_fb_helper.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 1c2b7d4..0f9e905 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -389,7 +389,7 @@ int drm_fb_helper_blank(int blank, struct fb_info *info) > break; > /* Display: Off; HSync: On, VSync: On */ > case FB_BLANK_NORMAL: > - drm_fb_helper_off(info, DRM_MODE_DPMS_ON); > + drm_fb_helper_off(info, DRM_MODE_DPMS_STANDBY); > break; > /* Display: Off; HSync: Off, VSync: On */ > case FB_BLANK_HSYNC_SUSPEND: Nak. The problem is the intel drm drivers doesn't handle it power management state seperate from the encoder state. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
> > > On 01/07/2010 12:42 AM, Johan Hovold wrote: > > > >> Yeap. The fix uncovered a bug in your driver. I haven't heard of > > > >> problems with the other drm drivers. > > > >> > > > >>> The backlight is handled via the DRI driver I assume. At least > > > >>> i9xx_crtc_dpms is called on powerdown. > > > >> > > > >> Can you post your dmesg and kernel config. > > > > > > [snip] > > > > > > Adding the Intel DRM people in CC as well. I have the same issue > > > with my GM45. > > > > Okay I looked at the code to figure out what is happening and why > > only this driver has problems. The problem is that the framebuffer > > layer expects the backlight to be a seperate device. The reason being > > is that some embedded systems will use a gpio backlight. That way > > power management for a graphics card/backlight has 3 seperate states. > > Currently the intel DRM driver treats the backlight as being apart of > > the encoder. Jesse do you have objections to having the intel driver > > expose a backlight device. The bonus of that is the user can also set > > the backlight levels. > > On Intel we usually expect the backlight to be exposed by ACPI or a > platform driver. On recent platforms, the ACPI driver will actually > send requests to the gfx driver to do the actual register writes to > adjust the backlight, but it's still ACPI driven. > > Maybe we just need to wire up the fb backlight hooks appropriately? I'm about to work up a patch And I noticed that drm-next and drm-intel-next are very different. Which tree should I use? Second is it possible for a card to support more than one backlight. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
> > Yeap. I can have patch ready for you this weekend. I lack the hardware to > > test it tho. Never been able to find a intel pci card that is not built > > into the motherboard. > > They don't exist, other than the old i740s. I noticed the same is true for SiS cards. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
> > > On 01/07/2010 12:42 AM, Johan Hovold wrote: > > > >> Yeap. The fix uncovered a bug in your driver. I haven't heard of > > > >> problems with the other drm drivers. > > > >> > > > >>> The backlight is handled via the DRI driver I assume. At least > > > >>> i9xx_crtc_dpms is called on powerdown. > > > >> > > > >> Can you post your dmesg and kernel config. > > > > > > [snip] > > > > > > Adding the Intel DRM people in CC as well. I have the same issue > > > with my GM45. > > > > Okay I looked at the code to figure out what is happening and why > > only this driver has problems. The problem is that the framebuffer > > layer expects the backlight to be a seperate device. The reason being > > is that some embedded systems will use a gpio backlight. That way > > power management for a graphics card/backlight has 3 seperate states. > > Currently the intel DRM driver treats the backlight as being apart of > > the encoder. Jesse do you have objections to having the intel driver > > expose a backlight device. The bonus of that is the user can also set > > the backlight levels. > > On Intel we usually expect the backlight to be exposed by ACPI or a > platform driver. On recent platforms, the ACPI driver will actually > send requests to the gfx driver to do the actual register writes to > adjust the backlight, but it's still ACPI driven. > > Maybe we just need to wire up the fb backlight hooks appropriately? Yeap. I can have patch ready for you this weekend. I lack the hardware to test it tho. Never been able to find a intel pci card that is not built into the motherboard. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
> On 01/07/2010 12:42 AM, Johan Hovold wrote: > >> Yeap. The fix uncovered a bug in your driver. I haven't heard of problems > >> with the other drm drivers. > >> > >>> The backlight is handled via the DRI driver I assume. At least > >>> i9xx_crtc_dpms is called on powerdown. > >> > >> Can you post your dmesg and kernel config. > > [snip] > > Adding the Intel DRM people in CC as well. I have the same issue with my > GM45. Okay I looked at the code to figure out what is happening and why only this driver has problems. The problem is that the framebuffer layer expects the backlight to be a seperate device. The reason being is that some embedded systems will use a gpio backlight. That way power management for a graphics card/backlight has 3 seperate states. Currently the intel DRM driver treats the backlight as being apart of the encoder. Jesse do you have objections to having the intel driver expose a backlight device. The bonus of that is the user can also set the backlight levels. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
> > > Commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e (drm/kms: properly > > > handle fbdev blanking) breaks console blanking on my laptop (GM45 > > > chipset). Instead of blanking the screen, it is dimmed and then the > > > backlight starts "glowing" in the lower edges of the screen. The glowing > > > then slowly spreads upwards. Does not look healthy at all... > > > > > > This patch reverts to the old behaviour of going directly to > > > DPMS_STANDBY. > > > > The current fbdev blank is correct. Normal blanking doesn't power down > > the hsync or the vsync signals. If you look at fbdev drivers you will see > > this type of behavior. If you want a full power down then a > > FB_BLANK_POWERDOWN > > is needed. As for the blacklight that is a another problem not related to > > this issue. The fbdev layer sends a event to the backlight layer to tell > > it to power down. That powerdown happens for the backlight in all cases > > except FB_BLANK_UNBLANK. How is your backlight setup. Is the backlight > > handled via the DRI driver or acpi? > > > > The change itself looks correct but it triggers something that seems to > hurt my screen bad. :) Yeap. The fix uncovered a bug in your driver. I haven't heard of problems with the other drm drivers. > The backlight is handled via the DRI driver I assume. At least > i9xx_crtc_dpms is called on powerdown. Can you post your dmesg and kernel config. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
> Commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e (drm/kms: properly > handle fbdev blanking) breaks console blanking on my laptop (GM45 > chipset). Instead of blanking the screen, it is dimmed and then the > backlight starts "glowing" in the lower edges of the screen. The glowing > then slowly spreads upwards. Does not look healthy at all... > > This patch reverts to the old behaviour of going directly to > DPMS_STANDBY. The current fbdev blank is correct. Normal blanking doesn't power down the hsync or the vsync signals. If you look at fbdev drivers you will see this type of behavior. If you want a full power down then a FB_BLANK_POWERDOWN is needed. As for the blacklight that is a another problem not related to this issue. The fbdev layer sends a event to the backlight layer to tell it to power down. That powerdown happens for the backlight in all cases except FB_BLANK_UNBLANK. How is your backlight setup. Is the backlight handled via the DRI driver or acpi? > Signed-off-by: Johan Hovold > --- > drivers/gpu/drm/drm_fb_helper.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 1b49fa0..9008583 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -389,7 +389,7 @@ int drm_fb_helper_blank(int blank, struct fb_info *info) > break; > /* Display: Off; HSync: On, VSync: On */ > case FB_BLANK_NORMAL: > - drm_fb_helper_off(info, DRM_MODE_DPMS_ON); > + drm_fb_helper_off(info, DRM_MODE_DPMS_STANDBY); > break; > /* Display: Off; HSync: Off, VSync: On */ > case FB_BLANK_HSYNC_SUSPEND: > -- > 1.6.6 > > -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Fri, 20 Nov 2009, Paulius Zaleckas wrote: > On 11/20/2009 10:01 PM, James Simmons wrote: > > > > > > > > Paulius Zaleckas wrote: > > > > > > > On drivers using drm_fb_helper's in fb_ops it is not possible to > > > > > > > change > > > > > > > video mode, because of different var->pixclock evaluation: ... > > > > > > > > > > > > patch: > > > > > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html > > > > > > > > > > Those patches will enable fbdev apps to run properly. More patches are > > > > > needed if you want to support mode switching using the fbdev emulation > > > > > layer. I noticed my patches and yours where lost. Who do you send > > > > > patches > > > > > too that can merge them ? > > > > > > > > y:/usr/src/git26> perl scripts/get_maintainer.pl -f > > > > drivers/gpu/drm/drm_fb_helper.c > > > > David Airlie > > > > Dave Airlie > > > > Jesse Barnes > > > > Mikael Pettersson > > > > dri-devel@lists.sourceforge.net > > > > linux-ker...@vger.kernel.org > > > > > > > > That's accurate enough. > > > > > > > > Generally, if nothing has happened in a week, the chances that it's > > > > lost are very high. Resend. If you like, cc me and I'll maintain the > > > > patches > > > > and resend them for you. > > > > > > You can add Tested-by: Paulius Zaleckas > > > for > > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html > > > as this was preventing DirectFB from running on my Asus Eee PC 701. > > > > I tested it as well with the both my 3Dfx driver that I wrote with KMS and > > the nouveau driver. We just need to make sure that the patches end up in > > the drm-next tree or these patches will be lost when drm-next gets merged > > to linus tree. > > IMHO this patch should end up in current (2.6.32) kernel and we should > send it to stable ML. Honestly I like to see it there as well. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> > > > Paulius Zaleckas wrote: > > > > > On drivers using drm_fb_helper's in fb_ops it is not possible to > > > > > change > > > > > video mode, because of different var->pixclock evaluation: ... > > > > > > > > patch: > > > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html > > > > > > Those patches will enable fbdev apps to run properly. More patches are > > > needed if you want to support mode switching using the fbdev emulation > > > layer. I noticed my patches and yours where lost. Who do you send patches > > > too that can merge them ? > > > > y:/usr/src/git26> perl scripts/get_maintainer.pl -f > > drivers/gpu/drm/drm_fb_helper.c > > David Airlie > > Dave Airlie > > Jesse Barnes > > Mikael Pettersson > > dri-devel@lists.sourceforge.net > > linux-ker...@vger.kernel.org > > > > That's accurate enough. > > > > Generally, if nothing has happened in a week, the chances that it's > > lost are very high. Resend. If you like, cc me and I'll maintain the > > patches > > and resend them for you. > > You can add Tested-by: Paulius Zaleckas > for http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html > as this was preventing DirectFB from running on my Asus Eee PC 701. I tested it as well with the both my 3Dfx driver that I wrote with KMS and the nouveau driver. We just need to make sure that the patches end up in the drm-next tree or these patches will be lost when drm-next gets merged to linus tree. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
> Paulius Zaleckas wrote: > > On drivers using drm_fb_helper's in fb_ops it is not possible to change > > video mode, because of different var->pixclock evaluation: ... > > patch: > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Fix oops when set_base is call with no FB
> On Tue, 2009-11-10 at 14:30 -0800, Andrew Morton wrote:
> > On Wed, 4 Nov 2009 20:03:19 +0100
> > Jerome Glisse wrote:
> >
> > > Just do nothings crct_set_base i call with no FB.
> > >
> >
> > hmpf. It's obvious that you spent hours carefully describing this
> > patch for us.
> >
>
> Sorry, truth is i don't understand why crtc set_base call back
> can be call with a null fb, i did just replicate what intel kms
> and other part of radeon kms was doing in front of such situation.
> It should go down to 2.6.31, useless before as there is no KMS
> for radeon in earlier version. The oops will happen when user
> switch btw X & vt or in some case when changing mode.
>
> Will clearly state my ignorance in future patch.
The secert to understanding why a oops occurs is to look at the
function drm_crtc_helper_set_config in drm_crtc_helper.c. This function is
called by both drm_fb_helper_set_par and drm_fb_helper_pan_display as
well as from userland attempting to set a mode via the dri layer. The
code path for this last case is drm_mode_setcrtc in drm_crtc.c.
In the userland setting case drm_mode_setcrtc() test to see if a
drm_framebuffer is avaliable. Either by user requesting a specific fb or
by using the default fb from the drm_crtc. If no fb is found then the
function returns a error. So the user must prepare a framebuffer before
hand.
Now the second case is the fbdev emulation layer calling
drm_crtc_helper_set_config. First in this method we have two states,
mode_change and fb_change. The first test is to see if crtc->fb equals
the desired fb. If the crtc->fb or the desired fb is NULL it is considered
a full mode change. If we have do have both fb which are not the same
objects then we expect a fb_change. This is true also we want any panning.
After that we test if the drm_display_mode passed in and the crtc->mode
are equal. If not then it is a mode_change. Now if the driver doesn't
support set_base then it is always a mode_change.
After all the testing we are ready to change the hardware state.
In the mode_change case we save the original fb which is crtc->fb. Then we
set the crtc->fb to the new fb and then call our function.
old_fb = set->crtc->fb;
set->crtc->fb = set->fb;
...
drm_crtc_helper_set_mode(set->crtc, set->mode, set->x, set->y,
old_fb)
In the fb_change case we also shuffle the fbs like above and call the
following.
old_fb = set->crtc->fb;
if (set->crtc->fb != set->fb)
set->crtc->fb = set->fb;
ret = crtc_funcs->mode_set_base(set->crtc, set->x, set->y,
old_fb);
Okay now to the problem with the fbdev emulation layer. If you look at
drm_fb_helper_single_fb_probe you will notice a new drm_framebuffer could
be created. Now the following field at set to this new fb:
modeset->fb
fb_helper->fb
If you notice no crtc->fb is set. This what causes the problems. Even more
interesting is the conditional check in drm_fb_helper_set_par.
if (crtc->fb == fb_helper->crtc_info[i].mode_set.fb) {
But because crtc->fb is null the mode is never changed. I repeat the
set_par function never changes the graphics mode. The worst part is the
var for the framebuffer console ends up out of sync with the dri layer
if someone attempts to change the mode via the fbdev layer. So what is
setting the default graphics mode. Actually it's the panning function
drm_fb_helper_pan_display. You will notice that the fb is never checked
there.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/kms: allocate framebuffer cmap
> Without an allocated colormap, FBIOGETCMAP fails. This would make
> programs restore an all-black colormap ("links -g") or fail to work
> altogether ("mplayer -vo fbdev2").
>
> Signed-off-by: Clemens Ladisch
> ---
> v2: implemented suggestions by James Simmons
>
> drivers/gpu/drm/drm_fb_helper.c | 4
> 1 file changed, 4 insertions(+)
>
> --- linux-2.6/drivers/gpu/drm/drm_fb_helper.c
> +++ linux-2.6/drivers/gpu/drm/drm_fb_helper.c
> @@ -905,6 +905,9 @@ int drm_fb_helper_single_fb_probe(struct
>
> if (new_fb) {
> info->var.pixclock = 0;
> + ret = fb_alloc_cmap(&info->cmap, crtc->gamma_size, 0);
> + if (ret)
> + return ret;
> if (register_framebuffer(info) < 0) {
fb_dealloc_cmap(info->cmap);
> return -EINVAL;
}
Plug memory leak.
> } else {
> @@ -936,6 +939,7 @@ void drm_fb_helper_free(struct drm_fb_he
> unregister_sysrq_key('v', &sysrq_drm_fb_helper_restore_op);
> }
> drm_fb_helper_crtc_free(helper);
> + fb_dealloc_cmap(&helper->fb->fbdev->cmap);
> }
> EXPORT_SYMBOL(drm_fb_helper_free);
>
>
>
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 3/3] drm/i915: allocate framebuffer cmap
> Without an allocated colormap, FBIOGETCMAP fails. This would make
> programs restore an all-black colormap ("links -g") or fail to work
> altogether ("mplayer -vo fbdev2").
>
> Signed-off-by: Clemens Ladisch
> ---
> Untested.
>
> --- linux-2.6/drivers/gpu/drm/i915/intel_fb.c
> +++ linux-2.6/drivers/gpu/drm/i915/intel_fb.c
> @@ -227,6 +227,10 @@ static int intelfb_create(struct drm_dev
>
> fb->fbdev = info;
>
> + ret = fb_alloc_cmap(&info->cmap, 256, 0);
> + if (ret)
> + goto out_unpin;
> +
> par->intel_fb = intel_fb;
>
> /* To allow resizeing without swapping buffers */
It would be better to place that code in drm_fb_helper_single_fb_probe.
Also instead of 256 I would recommend using crtc->gamma_size.
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
properly handle fbdev blanking
I examines several fbdev drivers and foudn the blanking code in
drm_fb_helper to be wrong. This patch fixes the fbdev blanking to behave
like other fbdev drivers.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index dc8e374..68061fc 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -373,11 +373,9 @@ static void drm_fb_helper_off(struct fb_info *info, int
dpms_mode)
mutex_unlock(&dev->mode_config.mutex);
}
}
- if (dpms_mode == DRM_MODE_DPMS_OFF) {
- mutex_lock(&dev->mode_config.mutex);
- crtc_funcs->dpms(crtc, dpms_mode);
- mutex_unlock(&dev->mode_config.mutex);
- }
+ mutex_lock(&dev->mode_config.mutex);
+ crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
+ mutex_unlock(&dev->mode_config.mutex);
}
}
}
@@ -385,18 +383,23 @@ static void drm_fb_helper_off(struct fb_info *info, int
dpms_mode)
int drm_fb_helper_blank(int blank, struct fb_info *info)
{
switch (blank) {
+ /* Display: On; HSync: On, VSync: On */
case FB_BLANK_UNBLANK:
drm_fb_helper_on(info);
break;
+ /* Display: Off; HSync: On, VSync: On */
case FB_BLANK_NORMAL:
- drm_fb_helper_off(info, DRM_MODE_DPMS_STANDBY);
+ drm_fb_helper_off(info, DRM_MODE_DPMS_ON);
break;
+ /* Display: Off; HSync: Off, VSync: On */
case FB_BLANK_HSYNC_SUSPEND:
drm_fb_helper_off(info, DRM_MODE_DPMS_STANDBY);
break;
+ /* Display: Off; HSync: On, VSync: Off */
case FB_BLANK_VSYNC_SUSPEND:
drm_fb_helper_off(info, DRM_MODE_DPMS_SUSPEND);
break;
+ /* Display: Off; HSync: Off, VSync: Off */
case FB_BLANK_POWERDOWN:
drm_fb_helper_off(info, DRM_MODE_DPMS_OFF);
break;
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: typo fix
> > Indeed this seems to be a typo, the important thing is to get someone > > like Dave Airlie to pick it up. > > > Yup I've picked this up in my queue. Do you have a time window where only bug fixes go in versus improvements? If that is the case what are the time schedules. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
fb_videomode to display_mode
Hi!
This patch takes a little explaining. After the cleaned up of the fbdev
api a few years back I realized the fbdev api had many short comings. One
of them was the mapping of 1 to 1 for the framebuffer to display. So I
started to move that way gradually. What ended up was a new struct
fb_videomode. It is used for the modedb code and the idea was we over time
would move away from fb_var_screeeninfo. It never happened but now that
dri is doing mode setting its a clean slate. Future patches will uses
these functions. Note a nice bonus is that fb_videomode always does the
right thing when it comes to the pixclock.
I have tested these patch with a KMS enabled tdfx driver port I have done.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9c92461..d020e57 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -755,6 +755,60 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
*var,
}
EXPORT_SYMBOL(drm_fb_helper_pan_display);
+void drm_display_mode_to_fbmode(struct drm_display_mode *mode,
+struct fb_videomode *fbmode)
+{
+ fbmode->xres = mode->hdisplay;
+ fbmode->yres = mode->vdisplay;
+ fbmode->right_margin = mode->hsync_start - mode->hdisplay;
+ fbmode->lower_margin = mode->vsync_start - mode->vdisplay;
+ fbmode->hsync_len = mode->hsync_end - mode->hsync_start;
+ fbmode->vsync_len = mode->vsync_end - mode->vsync_start;
+ fbmode->left_margin = mode->htotal - mode->hsync_end;
+ fbmode->upper_margin = mode->vtotal - mode->vsync_end;
+ fbmode->refresh = mode->vrefresh;
+ fbmode->name = mode->name;
+
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ fbmode->vmode |= FB_VMODE_INTERLACED;
+
+ if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ fbmode->vmode |= FB_VMODE_DOUBLE;
+
+ /* Doing a var to fb_videomode always create a proper pixclock
+* we can trust, but the reverse is not true. So we create
+* a proper pixclock from the refresh rate wanted. */
+ fbmode->pixclock = mode->vrefresh * mode->vtotal;
+ fbmode->pixclock *= mode->htotal;
+ fbmode->pixclock /= 1000;
+ fbmode->pixclock = KHZ2PICOS(fbmode->pixclock);
+}
+EXPORT_SYMBOL(drm_display_mode_to_fbmode);
+
+void fbmode_to_drm_display_mode(struct fb_videomode *fbmode,
+struct drm_display_mode *mode)
+{
+ mode->hdisplay = fbmode->xres;
+ mode->vdisplay = fbmode->yres;
+ mode->hsync_start = mode->hdisplay + fbmode->right_margin;
+ mode->vsync_start = mode->vdisplay + fbmode->lower_margin;
+ mode->hsync_end = mode->hsync_start + fbmode->hsync_len;
+ mode->vsync_end = mode->vsync_start + fbmode->vsync_len;
+ mode->htotal = mode->hsync_end + fbmode->left_margin;
+ mode->vtotal = mode->vsync_end + fbmode->upper_margin;
+ mode->vrefresh = fbmode->refresh;
+ mode->clock = PICOS2KHZ(fbmode->pixclock);
+
+ if ((fbmode->vmode & FB_VMODE_MASK) == FB_VMODE_INTERLACED)
+ mode->flags |= DRM_MODE_FLAG_INTERLACE;
+
+ if ((fbmode->vmode & FB_VMODE_MASK) == FB_VMODE_DOUBLE)
+ mode->flags |= DRM_MODE_FLAG_DBLSCAN;
+
+ drm_mode_set_name(mode);
+}
+EXPORT_SYMBOL(fbmode_to_drm_display_mode);
+
int drm_fb_helper_single_fb_probe(struct drm_device *dev,
int preferred_bpp,
int (*fb_create)(struct drm_device *dev,
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
typo fix
I believe this is a typo.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9c92461..dc8e374 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -707,7 +707,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
if (crtc->fb == fb_helper->crtc_info[i].mode_set.fb) {
mutex_lock(&dev->mode_config.mutex);
- ret =
crtc->funcs->set_config(&fb_helper->crtc_info->mode_set);
+ ret =
crtc->funcs->set_config(&fb_helper->crtc_info[i].mode_set);
mutex_unlock(&dev->mode_config.mutex);
if (ret)
return ret;
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
modeset repo
What is the git path for the mdoeset repo. I have some patches I like to submit. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: waitforVBlank, how does this even work?
> > Ultimatly this is the goal. That is what the struct xxx_par is for in > > struct fb_info. It is the core driver private data that can be shared by > > everyone. Ben would you mind if I reworked your code to have this "core". > > It will take me some time but I can have it working. I need to do some > > fixes for multiple monitor handling anyways. > > Wait, wait ... there is already Jon working on the driver, and I plan to > include part of his recent work along with some initial dual head > support soon, let's avoid having too many people working at the same > time on it. I have seen his patches. He post them:-) The way it is being done is not according to the fbev api spec. I like to see it done right. Alot of drivers never where ported properly to the new api. People ported as fast as they could instead of properly. > Also, with the merge DRM/fbdev, this will become a non-issue, wether the > ioctl comes from DRM or fbdev, we'll be able to do the right thing. Ture but that is down the road. The idea is to share the par between the two different systems. --- 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=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: waitforVBlank, how does this even work?
> Hi Jon, > > What about isolating interrupt-handling code into a small driver ? > Something simple to respond to interrupts and call all handlers with a > certain mask. > > This would be useful not only for drm and fbdev but also for km > (v4l capture module) and stereo-glasses code. Ultimatly this is the goal. That is what the struct xxx_par is for in struct fb_info. It is the core driver private data that can be shared by everyone. Ben would you mind if I reworked your code to have this "core". It will take me some time but I can have it working. I need to do some fixes for multiple monitor handling anyways. --- 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=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Resource management.
> As far as I know none of the significant contributors on either fbdev > or DRM are being paid to work on the project. So I have noticed. There is much to do but no real man power. We are talking about this merging but at our rate it will take 5 years to happen. We don't have the man power to do this. So I'm not going to bother merging. Its all pipe dreams here. --- 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=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Resource management.
> > 1. Lots of work that would take lots of time. To my knowledge all fbdev > >developers work in there spare free time. No one does this for a > >living. > > So do most of the drm developers, I know I do and Jon Smirl does, and > Eric Anholt does and I think us three have been the largest > contributers apart from new driver submissions... Ug :-( That is sad!!! > > 2. Sharing of headers. The dri headers are isolated in the drm directory. > >I totally understand why :-) It makes merging easier for them. The > >disadvantage is no one in the fbdev can use them easily :-( > > I plan to move them in 2.6.12 maybe .. it might be 2.6.13 by the time > I get around to it, just some minor issues.. Arjan asked me for this > ages ago as well... Okay. Where will they go? include/video ? > > 3. DRM has way to much functionality for most embedded devices. I have > >talked to embedded guys before and they want a simple api to work with. > >By default DRM builds in everything. A simple api mean alot to those > >guys. Plus the extra built in code bloat takes up to much space which > >is precious on embedded devices. If a devices doesn't support dma then > >the dma code doesn't need to be built in. > > Well crap on that, the old DRM didn't build everything in people > complained aw this code is too messy, build everything in, now you > want to revert? damn you all!!! :-), Ha Ha. I didn't know the history. > I understand I'm just saying we > can't have it both ways.. and too be honest I'm an embedded person and > I just want it to work, with a Linux kernel you rarely get to an every > byte counts embedded env, of if you are you aren't using the stock > Linus kernel I can live with this issue as long it would not increase the complexity of framebuffer only devices. Simple api is very important to me. The current fbdev api is designed to be very simple for the most common cases. It can get complex tho with exotic hardware. > > 4. Which comes to the next point. The code is not modular enough. Take > >drm_bufs.c. Everything is a ioctl function. This has a few disadvantages. > >One is the fbdev layer couldn't just link into it so fbcon could use > >it. The second is it's not easy to take advantage of things like sysfs. > >If you could untangle the code somewhat it would make life so much > >easier. That would include making life easier for OS ports. > > the reason we can't take advantage of sysfs or anything like it is > that we can't bind to the PCI device as we break things.. this is the > root of a lot of our problems... Is this because you want to be OS portable? This makes things very very hard to merge. Fbdev attempts to take advantage the most powerful linux kernel features. > > 5. The license issue. The DRI code is GPL and additional rights. What is > > that? > Nope the drm code is BSD... there should be no GPL anywhere near it... > it is GPL in the kernel as of course it is imported into a GPL work.. > but the code is available for BSD uses If it is GPL in the kernel then that is fine. We can work with that. I don't care about userland code. > Jon's last plan - was like to have a radeon basic module, with fb and > drm personalities and in fact any number of personalities..taking > radeon as example: > base module : hotplug, reset, monitor probing, memory management, CP > programming and locking. > fb: adds accelerated fb functions using CP locking. > drm: adds drm functionality on top of base module, drm ioctl interfaces etc.. That will be a huge amount of work! BTW what does CP stand for? > I've looked at Alans ideas on a vga_class driver and have decided they > are unworkable due to the massive initial changes they involve in > *every* fb/drm driver in the kernel, I cannot undertake a work of that > magnitude without fb people being involved and the chances of breaking > a lot of stuff.. maybe a 2.7 thing but I don't think we'll ever have a > 2.7 for this stuff... > > What I do think though is that ideas of a the vga class driver could > be made into a helper module that the base graphics driver uses to do > some standard things, like reset and stuff.. > > I'm hoping to get a better handle on these ideas and write something > up.. but they are mostly Jons ideas better presented :-) As for the VGA class driver. We already have something like that for the fbdev layer. Take a look at vgastate.c. It was written originally so you could go from vgacon to fbdev without fbcon and back to vgacon state again. It also has common functions for all the drivers to work with. I already asked Jon to merge his work with that code. That code could also be very useful for vgacon in the future. We need vga core management in the kernel. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products trul
Re: [Linux-fbdev-devel] Resource management.
> > Do you see any other solution to this then? > > You could build this inside of the DRM framework which already > supports DMA and memory management. DRM doesn't really know anything > about 3D, it just knows how to send commands to the graphics hardware. > It's the mesa layer in user space that knows about 3D. > > There is a lot of code inside DRM to stop a DRM user from using the > DMA hardware to play with kernel memory and gain root priv. fbdev will > need the same protection if it starts using DMA. I have CC the dri list to discuss the issues. I have looked at the DRI code. I know merging dri and fbdev infrastructres has been discussed before. There are a few issues that have always prevented this. Now I'm going to go over the issues. 1. Lots of work that would take lots of time. To my knowledge all fbdev developers work in there spare free time. No one does this for a living. 2. Sharing of headers. The dri headers are isolated in the drm directory. I totally understand why :-) It makes merging easier for them. The disadvantage is no one in the fbdev can use them easily :-( 3. DRM has way to much functionality for most embedded devices. I have talked to embedded guys before and they want a simple api to work with. By default DRM builds in everything. A simple api mean alot to those guys. Plus the extra built in code bloat takes up to much space which is precious on embedded devices. If a devices doesn't support dma then the dma code doesn't need to be built in. 4. Which comes to the next point. The code is not modular enough. Take drm_bufs.c. Everything is a ioctl function. This has a few disadvantages. One is the fbdev layer couldn't just link into it so fbcon could use it. The second is it's not easy to take advantage of things like sysfs. If you could untangle the code somewhat it would make life so much easier. That would include making life easier for OS ports. 5. The license issue. The DRI code is GPL and additional rights. What is that? For the fbdev layer we would need a layer on top of the drm data structures because we need to know things in the kernel to draw images for font characters i.e how much byte padding is need for images. --- 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=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
> What this is saying is that very early in the boot process the graphics driver > will be initialized. At this point it will generate a hotplug event. This event > will be handled by an app and lib that live in initramfs. This is not saying > that mode-setting will be delayed until normal user space starts. The initial > hotplug event occurs very early in the boot process, almost as early as the > current device driver based code runs. Right now alot of application including commerical depend on setting the video mode via /dev/fb. I like to have /sys do that in the future. If that goes away it will break alot of software. Hurt alot of companies. Now consider these apps in the future and how with the above will work. app -> /dev/fb to change mode -> context switch to kernel -> send hot plug event -> userland app grabs event -> loads library to execute the code if it hasn't done so already -> set mode in userland library -> via a ioctl creates a event packet to send back to kernel to let them know it worked. Also we need to send back detail data on the new mode for the app. We might of not got the exact mode we wanted so we send back the closes thing we wanted. -> context switch to kernel -> store new data kernel side. -> call library to grab new resolution data for a app. Now you could say we could remove the fbdev interface completely and move to the library. But then you have the below case. Now consider the case of a VC switch where two VC's are at different resolutions. Say one is at 80x30 and the other is 128x48 You press Alt-Fx -> VT code call console_callback -> send a hotplug event to userland -> a userland app gets the event -> loads the userland library -> executes the code to set the video mode -> send back a ok from userland. Again we need to send a packet back to kernel to let them know if it was successful. Also we need to let them know the exact details of the mode we actually got. -> context switch to kernel -> write new data to struct vc_data. This is a really expensive solution. 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. > This is very similar to the way udev works. Udev is a user space replacement for > devfs. Instead of having a /dev with 40,000 devices in it, udev builds one on > the fly at each boot with exactly your devices in it. Now that I have used udev > instead of devfs I have to agree that it is a much better solution. In fact the > udev app will run before the mode-setting app since it's the udev app that > creates the devices in /dev now by detecting additions to sysfs. udev FAQ: > http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ > We all know Linux is non-functional without a /dev directory, and now /dev is > being build in user space. I also like udev much more than devfs. The difference is that userland doesn't modify device nodes. You create them and you remove them. Very basic. Fbdev is a bit more complex than that. You can see that in the above arguments. > Andrew, akpm, has also explained to me that even the current fbdev is not > really active at boot. Instead those initial printk's are queued until > the fbdev driver initialized and prints them. That is true and I consider it a bug. The true is that the fbdev layer could be started right away for most of the drivers. Most fbdev devices are embedded devices which don't need a bus initialized first. Even on intel you could have the vga16 driver started at the exact same time as vgacon. The limitation is only for devices like pci. Personally I like to see fbcon start at the same time as vgacon and the rest and if the graphics card is pci then when it initializes then start drawing the data. --- 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
> > 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. --- 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] Re: Current discussion about the future of free software graphics
> Anyway. I've got a lot of respect for the people involved in the discussion, > even when they hold quite conflicting views, so I'm hopeful that some sort of > direction can be reached for moving forward. I apologize for getting over heated. I'm very protective of the companies that work in the embedded space. I don't want to see them go away. They are vitial to linux. I know this might get some people upset but IMNSHO the linux community is going after the wrong goal. Everyone keeps thinking desktop PC. We don't have the resources to win that war and second the PC is NOT the future. I work for a asian company and when you go to the asian rim you see that the latest technology is in the embedded space. Look all around you. Embedded devices are everywhere. In stoplights, cars, supermarkets, tv, dvd players. Next time you use your printer look at the little display. Guess what? That printer is most likely a linux box and that little display is a framebuffer devices. How do I know? Because I wrote that code for the last company I worked at. For the embedded space we do have the resources to win that area of the market if we provide the tools they need to succeed. What do most people use there laptops for. Mostly playing movies. I also see embedded devices coming to this market soon that do the same thing for alot less money. Even the 3D graphics market is moving away from the PC to game consoles. > My one worry about the discussion is that because of confusion over where the > X developers are hanging out nowadays, they are missing out on having their > say on this - and they probably care deeply about modesetting. Though, given > the mad flamewar it's turned into, maybe smaller is better... Sorry about the flamewar. --- 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
> > > > 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. It was a joke. --- 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
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. 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. > > > > > --- > 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 > ___ > Linux-fbdev-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > --- 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: Current discussion about the future of free software graphics
> 1: Design must provide a mechanism for basic mode setting in a
> device independent manner from an application with user level
> permissions. ("Basic" to be defined)
Ug. I see I'm fighting a losing battle but it doesn't matter. I couldn't
never win this fight. There is MONEY involved here. This is a sure way
to make sure Tungstengraphics has a income coming in. They want a monoply
on the linux graphics arena then fine they can have it.
---
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
> 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! I agree here. I apologize for my behavior. --- 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: [Mesa3d-dev] RE: [Dri-devel] Memory management of AGP and VRAM
> I'm not speaking about a text mode. > I would think on most systems the firmware would provide some reasonable > initial mode that the kernel can use. If there is no such firmware one > would expect there is some preboot software that is used to bootstrap the > kernel that could do such a setup - using a number of fixed modes hard > coded in tables. (It is a pain to debug, though). You haven't done to work much with embedded hardware. So instead of one graphics driver initailzing the hardware for every platform we need to force all the embedded companies out there to add code to there boot setups to initialize the different possible graphics cards out there. That is alot of duplicated work for nothing. --- 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: [Mesa3d-dev] Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
> On Mon, May 10, 2004 at 10:39:50PM +, Nicolas Souchu wrote: > > Do apps manage their swap? No. I think the OS should be responsible for > > placing the data (vertices, textures, commands) at the right/best place > > for the HW 3D engine and the client should only fill virtual memory. > > > http://www.freebsd.org/~nsouch/kgi4BSD > > Browsing through kgi.sf.net I found that they have proper multihead > and DDC2 support. They just lack DRI integrated into KGI and it will > rock from my user perspective. > > Is true that the BSDs are adopting KGI as their unified kernel > graphics layer? It looks like BSD is heading in the right direction. If this lame idea of a userland library goes threw I wil quite fbdev developement and go over to BSD then. Either that or fork the tree and start my company with my work. --- 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] Current discussion about the future of free software graphics
> single kernel driver should muck with the hardware directly. However, > I'd like to point out again that it doesn't follow that the DRM and the > framebuffer device must merge to a single entity (which 'has to be' the > DRM if you ask some people, the framebuffer device if you ask > others...). E.g., they could both use the same mini-driver which deals > with the hardware. Let's try and keep our minds open to all possible > solutions. I agree. The disagreement is about where to put mode setting. > > register values. Finally the plug-in lib would use a private IOCTL to set the > > state into the video hardware. > > > > There are numerous pros and cons for both a both schemes. The user space code is > > swappable, easier to debug, and does not need to be run as root. > > It does, or the ioctl must verify the register data, which could require > about the same amount of code as computing it in the kernel in the first > place (possibly even more; the problem changes from computing a valid > combination of register values for a specific requested mode to limiting > the huge number of register value combinations to those that don't lock > up the chip or worse). I've pointed this out several times before, but > nobody has presented a solution yet. Will the userspace code live in a > daemon that runs as root? Or will only privileged processes be allowed > to change display properties? So in reality having mode switching would be just as expensive in userspace as having it in the kernel? --- 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
> > But we are rendering to draw fonts, clearing a area of the screen,copyarea. > > If we are to have a universal solution it needs to OpenGL. Either that or > > mode switching stays in the kernel. > > Drawing fonts have _NOTING_ to do with mode switching ! Don't tell me > that you can't make the difference between fbdev and fbcon now ;) That is not what I'm saying. I'm sayimng we could use opengl to draw the fonts in fbcon. Opengl coudl be the center piece library that does everything. > > 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. > > Bloat bloat bloat. > > That has nothing to do with it. If you don't agree, come to KS or OLS > and talk to Linus. Your arguments & comparisons are pointless I think I'm going to have to. --- 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: [Mesa3d-dev] Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
> It's not just bloat, the network code is used millions of times per second. > Mode setting happens occaisonally. Using that logic then Sound cards shouldn't be in the kernel at all. I never use my sound card continuely. I use it as a module. Would it be acceptable if the mode setting was modular? > The other problem is memory management. What is going to happen when fbdev > starts setting the mode for both heads? Who is going to mananage the VRAM when > the buffers get resized? OpenGL has a very complex memory management scheme > where things can migrate from VRAM to AGP to system memory. I know problems like this are going to exist. So I guess the idea of the kernel supporting multi-desktops is out then. The ruby (linuxconsole) project has two independent workstations running on the G400 dual head cards. I guess that has to go :-( --- 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
> You are mixing things. Mode setting has nothing to do with rendering. OpenGL > is a rendering client. It produces commands sent to the low level kernel > driver and provides a 3D API, but it's not the only one. In this regard, > fbcon is a client too and XFree 2D accel is another one. But we are rendering to draw fonts, clearing a area of the screen,copyarea. If we are to have a universal solution it needs to OpenGL. Either that or mode switching stays in the kernel. 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. Bloat bloat bloat. --- 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: [Mesa3d-dev] RE: [Dri-devel] Memory management of AGP and VRAM
> Also, these is no rule saying a device driver can't have several tables of _init > register values that can be used to set the mode on a primary monitor at boot. I > would just like to see all of the code that does DDC decoding and modeline > computations moved to user space. When you add up that code there is about 40K > of it in the fbdriver and about 50K in the radeon driver. When the fbdev drivers > start probing for multiple heads, TV support, etc that code is going to get even > larger. Since the code is used only rarely (in kernel terms) this code should be > in user space instead of the driver. > > I've also proposed that if you really, really want to you could do the DDC > probing the in driver at boot and mark all of the code _init. Then the user > space code would take over after that. Note that I'm talking about early > userspace (initrd) timeframe, not normal user space. DDC probing is still new. I doubt it will be that large in the long run. I bet we will see redudency in the drivers that we seperate out. Give me time and I can show that it will be minimum code. --- 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
> But who cares? Do you really intend to keep a common BSD and Linux API/code base? > Offering both solutions under BSD and GPL would be good for suggesting correct > license usage in the embedded world. GPL is too often bypassed. What about a dual license. > > The big reason for merging is memory management. If FB supports multiple heads > > it is forced into doing memory management. DRI has memory management needs that > > go far beyond what FB needs so a merged system has to use DRM memory management. > > Ian has made proposals on how to do this and he is working on improving them. > > What is best? Bring modesetting to DRM or memory management to FB? Bring mode setting to DRM since all FB does is mode setting, color maps and 3 accel functions for the console. With sysfs we could bring both together. > > 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? The idea was to mount userland inside the kernel while booting and run a library to initialize the mode. We have two options: 1) Keep mode switching in the kernel. Merge DRI and fb together via sysfs interface. 2) Ben suggestion that we mount userland inside the kernel during early boot and use a userland library. If we would use a library then it MUST be OpenGL. This would be the forced standard on all platforms. This would mean Mesa would be needed to build the kernel. We could move over Mesa into the kernel like zlib is in the tree right now. --- 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
> > 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 ;-) The KGI is way to complex. I attempted to write a driver using that system but I was totally lost. Fbdev, especially now is much easier to develope. The input system we have is very similiar to what they had. I'm really glad we have a input system. As for the library. Well it has always been a dream to have a universal library by many people. It never happened and never will happen. When it comes it libraries you have issues like licenses and people fighting --- 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
> What is exactly your question concerning licenses? > > > Another topic that I missed was, why did kgi fail and what can we do to avoid > > repeating the same path this time around. > > KGI failed to be accepted by linus/linux. You surely don't want repeating > this ;) Otherwise, its design is still valid, I believe. My only complaint about KGI was the driver api was way to complex. I believe that one of the BSD use it. I forgot which one. The idea of only universal library never happened. Never will. --- 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] DRM and pci_driver conversion
> > I see your point about fbdev not beeing the proper interface here.
> >
> > But then, what would be the relationchip between that low level stuff
> > and fbdev ?
>
> My suggestion, as a starting point, is to really think very rudimentary at
> first. A truly _minimal_ thing. Minimal partly because that just avoids
> all the interface design issues ("there are none" ;), but partly because
> everybody involved will have rather different goals. In particular, the
> XFree86 people would have as a goal to keep the differences to a
> user-space implementation minimal, so in that sense you really want to
> have an abstraction that doesn't hide the hardware AT ALL.
>
> NOTE! I'm not saying this is necessarily the best interface or a truly
> great idea. This is just throwing out my thought of the day. I'm nothing
> if not flexible - some people think I change my mind _too_ often ;)
>
> So the thing should really just have
> - discovery and attach/detach
> - interrupt event notification (and it can't just be "an interrupt
>happened" - the interrupt driver actually has to know enough to ACK the
>interrupt, so that we can tell user space that an interrupt happened
>without having to disable the interrupt until the event goes away)
> - serialization (ie a lock) and waiting for events ("engine idle" or
>"command queue less than half full")
> - DMA arbitration and setup.
This is good design for DMA based graphics cards. Unfortunely at present
maybe one fbdev driver actaully uses DMA (i810fb). Almost all fbdev drivers
use IO access :-( Sure we could convert as many as possible to DMA, which I was
planning to do anyways :-)
> Most of the rest (actual IO accesses etc) can be done outside the lowlevel
> crud, once you have the lock. This is also why DMA really _is_ special,
> since it's asynchronous: so it can and does happen independently of the
> lock. But normal synchronous programmed IO doesn't need any real help, and
> there's no point in forcing that into the low-level driver. All the users
> might as well do any direct IO directly.
>
> So the low-level driver wouldn't know about palettes or cursors or any
> "high-level" concepts like that. It would have a few locks to make sure
> that the users that try to access the things don't stop on each other,
> nothing more (maybe the locks themselves would be grouped into "palette
> lock" vs "cursor lock" vs "DMA engine lock" since hardware may be threaded
> enough to allow it, but the point is that the low-level driver wouldn't
> actually _do_ anything, it only allows others to do what they want without
> stomping on each others toes).
Unfortunely most fbdev drivers set the hardware in IO access mode. Plus
some of the devices lack any kind of DMA support. In this case seperating
out the parts of the driver that program the "high level" stuff leaves
almost nothing left. Would it still be wise to seperate it out as you
suggest? Would we really gain that much doing this for the case of IO
access only graphics hardware?
> > This looks like just an extension of the current DRI modules, and having
> > things like fbdev stack on top of them...
>
> Quite the reverse, I think. It would be a _shrink_ of the DRI modules.
:-)
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Multiple drivers for same hardware:, was: DRM and pci_driver conversion
> Since they have to co-operate some way on the resources _anyway_, they'll > just need to work it out amongst themselves. > > One common case is to have a "arbitration driver" that tends to do the > actual low-level accesses and is one level of abstraction over the > hardware (papers over trivial differences in hardware). An example of this > would be the old-style ISA DMA infrastructure (now happily pretty much > dead), where the "DMA driver" was just a trivial layer that had some basic > allocation/deallocation and had somewhat nicer access routines than the > raw IO accesses, but didn't do much more. I already have thought ahead about this issue. That is why one of the major changes to the framebuffer layer was to seperate the driver data into struct fb_info and a struct xxx_par. The idea was the data in struct fb_info was for the framebuffer layer and the data in struct xxx_par could be shared with other interfaces like DRI. The par idea can be extended further and we could use a common structure between a low level text mode console driver and a graphics driver. For example mdacon and hgafb. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: dri fb drivers [was: Re: [Linux-fbdev-devel] Rage128 and Radeonpatches]
> > nice work! > > > > i know you are working with the dri fb drivers, is > > any progress and what is the current state? > > I am working on embedded Mesa, which is another name > for standalone OpenGL. Embedded Mesa is based on the > 3D DRI code but it handles 2D very differently. > > Xfree/DRI scans the PCI bus and initializes hardware > in it's user space process. Embedded Mesa instead > loads the framebuffer drivers and uses them to > initialize the hardware. This makes Embedded Mesa much > simpler since it relies on the framebuffer drivers for > a lot of things such as mode switching and PCI bus > scanning. > > You can get a snapshot of my work with this: > bk clone bk://mesa3d.bkbits.net/jonsmirl local_name > > Standalone OpenGL works for most all Radeon chips if > you also use the updated framebuffers. Rage128 and MGA > support and being worked on but they are not ready > yet. This is development level code and it is not > ready for testing. Oh wow. That is way to cool I suggest you merge your work with the khronos group. It would be really nice to see a embedded OpenML implementation. I'm looking into this since I plan to implement Java3D /JavaX media layer for GNU Classpath/Kaffe in the near future. http://www.khronos.org/ --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
