[RFC][PATCH 2/2] Add option to preserve aspect in SDL display scaling.
The output is not centered.
I am not sure how to achieve that because SDL just sets a video mode
which starts at upper left corner of the window.
It would be possible to make the mode larger but then the zoom routines
would have to take an offset.
Signed-off-by: Michal Suchanek hramr...@centrum.cz
---
qemu-options.hx | 13 +
ui/sdl.c| 13 +++--
vl.c|4
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index fd96b6a..bd25396 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -629,6 +629,19 @@ workspace more convenient.
ETEXI
#ifdef CONFIG_SDL
+DEF(keep-aspect, 0, QEMU_OPTION_preserve_aspect,
+-keep-aspectpreserve aspect ratio of display output\n,
+QEMU_ARCH_ALL)
+#endif
+STEXI
+...@item -keep-aspect
+...@findex -keep-aspect
+Normally the SDL output scales the guest display to fill the SDL window. With
+this option the guest display is scaled as large as possible preserving the
+aspect ratio possibly leaving some empty space in the window.
+ETEXI
+
+#ifdef CONFIG_SDL
DEF(alt-grab, 0, QEMU_OPTION_alt_grab,
-alt-grab use Ctrl-Alt-Shift to grab mouse (instead of Ctrl-Alt)\n,
QEMU_ARCH_ALL)
diff --git a/ui/sdl.c b/ui/sdl.c
index f599d42..5ac9a77 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -38,6 +38,7 @@
#include x_keymap.h
#include sdl_zoom.h
+int sdl_preserve_aspect = 0;
static DisplayChangeListener *dcl;
static SDL_Surface *real_screen;
static SDL_Surface *guest_screen = NULL;
@@ -65,12 +66,12 @@ static Notifier mouse_mode_notifier;
static void sdl_update(DisplayState *ds, int x, int y, int w, int h)
{
-//printf(updating x=%d y=%d w=%d h=%d\n, x, y, w, h);
SDL_Rect rec;
rec.x = x;
rec.y = y;
rec.w = w;
rec.h = h;
+//fprintf(stderr, SDL updating x=%d y=%d w=%d h=%d\n, x, y, w, h);
if (guest_screen) {
if (!scaling_active) {
@@ -105,7 +106,7 @@ static void do_sdl_resize(int new_width, int new_height,
int bpp)
{
int flags;
-//printf(resizing to %d %d\n, w, h);
+fprintf(stderr, SDL resizing to %d %d\n, new_width, new_height);
flags = SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL|SDL_RESIZABLE;
if (gui_fullscreen)
@@ -113,6 +114,14 @@ static void do_sdl_resize(int new_width, int new_height,
int bpp)
if (gui_noframe)
flags |= SDL_NOFRAME;
+if (guest_screen) {
+float wr = (float)new_width / (float) guest_screen-w,
+ hr = (float)new_height / (float) guest_screen-h,
+ r = (wr hr) ? hr : wr;
+new_width = (float)guest_screen-w * r + 0.5;
+new_height = (float)guest_screen-h * r + 0.5;
+fprintf(stderr, SDL adjusting resize to %d %d\n, new_width,
new_height);
+}
width = new_width;
height = new_height;
real_screen = SDL_SetVideoMode(width, height, bpp, flags);
diff --git a/vl.c b/vl.c
index ee641bc..67d35bb 100644
--- a/vl.c
+++ b/vl.c
@@ -193,6 +193,7 @@ QEMUClock *rtc_clock;
int vga_interface_type = VGA_NONE;
static int full_screen = 0;
#ifdef CONFIG_SDL
+extern int sdl_preserve_aspect;
static int no_frame = 0;
#endif
int no_quit = 0;
@@ -2421,6 +2422,9 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_no_frame:
no_frame = 1;
break;
+case QEMU_OPTION_preserve_aspect:
+sdl_preserve_aspect = 1;
+break;
case QEMU_OPTION_alt_grab:
alt_grab = 1;
break;
--
1.7.1
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC][PATCH 1/2] Add option to disable PS/2 mouse.
Hello
I tried to patch qemu to allow disabling the PS/2 mouse.
This patch works for me, when I disable the mouse Windows no longer
detects it.
I am not sure this is entirely correct. Specifically there is
KBD_MODE_DISABLE_MOUSE bit which can probably still be disabled and
KBD_MODE_MOUSE_INT is enabled.
Thanks
Michal
Signed-off-by: Michal Suchanek hramr...@centrum.cz
---
hw/isa.h|1 +
hw/pckbd.c | 36 +---
qemu-options.hx |9 +
vl.c|4
4 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/hw/isa.h b/hw/isa.h
index aaf0272..80ab6bb 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -31,6 +31,7 @@ ISADevice *isa_create(const char *name);
ISADevice *isa_create_simple(const char *name);
extern target_phys_addr_t isa_mem_base;
+extern int isa_psaux;
void isa_mmio_init(target_phys_addr_t base, target_phys_addr_t size, int be);
diff --git a/hw/pckbd.c b/hw/pckbd.c
index 6e4e406..4557e14 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -169,7 +169,7 @@ static void kbd_update_irq(KBDState *s)
}
}
qemu_set_irq(s-irq_kbd, irq_kbd_level);
-qemu_set_irq(s-irq_mouse, irq_mouse_level);
+if (s-mouse) qemu_set_irq(s-irq_mouse, irq_mouse_level);
}
static void kbd_update_kbd_irq(void *opaque, int level)
@@ -205,10 +205,11 @@ static uint32_t kbd_read_status(void *opaque, uint32_t
addr)
static void kbd_queue(KBDState *s, int b, int aux)
{
-if (aux)
-ps2_queue(s-mouse, b);
-else
+if (aux) {
+if (s-mouse) ps2_queue(s-mouse, b);
+} else {
ps2_queue(s-kbd, b);
+}
}
static void ioport92_write(void *opaque, uint32_t addr, uint32_t val)
@@ -323,12 +324,13 @@ static void kbd_write_command(void *opaque, uint32_t
addr, uint32_t val)
static uint32_t kbd_read_data(void *opaque, uint32_t addr)
{
KBDState *s = opaque;
-uint32_t val;
+uint32_t val = 0;
-if (s-pending == KBD_PENDING_AUX)
-val = ps2_read_data(s-mouse);
-else
+if (s-pending == KBD_PENDING_AUX) {
+if (s-mouse) val = ps2_read_data(s-mouse);
+} else {
val = ps2_read_data(s-kbd);
+}
DPRINTF(kbd: read data=0x%02x\n, val);
return val;
@@ -354,13 +356,13 @@ static void kbd_write_data(void *opaque, uint32_t addr,
uint32_t val)
kbd_queue(s, val, 0);
break;
case KBD_CCMD_WRITE_AUX_OBUF:
-kbd_queue(s, val, 1);
+if (s-mouse) kbd_queue(s, val, 1);
break;
case KBD_CCMD_WRITE_OUTPORT:
ioport92_write(s, 0, val);
break;
case KBD_CCMD_WRITE_MOUSE:
-ps2_write_mouse(s-mouse, val);
+if (s-mouse) ps2_write_mouse(s-mouse, val);
break;
default:
break;
@@ -430,9 +432,10 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
{
KBDState *s = qemu_mallocz(sizeof(KBDState));
int s_io_memory;
+int mouse_enabled = isa_psaux;
s-irq_kbd = kbd_irq;
-s-irq_mouse = mouse_irq;
+if (mouse_enabled) s-irq_mouse = mouse_irq;
s-mask = mask;
vmstate_register(NULL, 0, vmstate_kbd, s);
@@ -440,7 +443,8 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
cpu_register_physical_memory(base, size, s_io_memory);
s-kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
-s-mouse = ps2_mouse_init(kbd_update_aux_irq, s);
+s-mouse = NULL;
+if (mouse_enabled) s-mouse = ps2_mouse_init(kbd_update_aux_irq, s);
qemu_register_reset(kbd_reset, s);
}
@@ -454,7 +458,7 @@ void i8042_isa_mouse_fake_event(void *opaque)
ISADevice *dev = opaque;
KBDState *s = (DO_UPCAST(ISAKBDState, dev, dev)-kbd);
-ps2_mouse_fake_event(s-mouse);
+if (s-mouse) ps2_mouse_fake_event(s-mouse);
}
void i8042_setup_a20_line(ISADevice *dev, qemu_irq *a20_out)
@@ -478,9 +482,10 @@ static const VMStateDescription vmstate_kbd_isa = {
static int i8042_initfn(ISADevice *dev)
{
KBDState *s = (DO_UPCAST(ISAKBDState, dev, dev)-kbd);
+int mouse_enabled = isa_psaux;
isa_init_irq(dev, s-irq_kbd, 1);
-isa_init_irq(dev, s-irq_mouse, 12);
+if (mouse_enabled) isa_init_irq(dev, s-irq_mouse, 12);
register_ioport_read(0x60, 1, 1, kbd_read_data, s);
register_ioport_write(0x60, 1, 1, kbd_write_data, s);
@@ -490,7 +495,8 @@ static int i8042_initfn(ISADevice *dev)
register_ioport_write(0x92, 1, 1, ioport92_write, s);
s-kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
-s-mouse = ps2_mouse_init(kbd_update_aux_irq, s);
+s-mouse = NULL;
+if (mouse_enabled) s-mouse = ps2_mouse_init(kbd_update_aux_irq, s);
qemu_register_reset(kbd_reset, s);
return 0;
}
diff --git a/qemu-options.hx b/qemu-options.hx
index a0b5ae9..fd96b6a 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1746,6 +1746,15 @@ Three button serial mouse. Configure the guest to use
Microsoft protocol.
@end table
ETEXI
+DEF(no-psaux, 0, QEMU_OPTION_nopsaux, \
+-no-psaux disable PS/2 mouse\n
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 10 March 2010 22:04, Ville Syrjälä syrj...@sci.fi wrote: On Wed, Mar 10, 2010 at 06:11:29PM +, James Simmons wrote: 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. matroxfb does have a bunch of custom ioctls to change the crtc-output mapping. omapfb is another multihead fb driver and it's more complex than matroxfb. Trying to make it perform various tricks through the fbdev API (and a bunch of custom ioctls, and a bunch of sysfs knobs) is something I've been doing but I would not recommend it for anyone who has the option of using a better API. 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. 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. Thanks Michal -- Download Intel#174; 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 10 March 2010 19:47, James Simmons jsimm...@infradead.org wrote: 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. Ability to print the oops over X does not seem to be that bad idea. Since with KMS the kernel finally knows what X is doing with the graphics it should be able to print it. Note that it may be the only way to see it in situations when the console dies in one way or another. Thanks Michal -- Download Intel#174; 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 10 March 2010 18:42, James Simmons jsimm...@infradead.org 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? 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. 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. Thanks Michal -- Download Intel#174; 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 11 March 2010 16:17, James Simmons jsimm...@infradead.org 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. Thanks Michal -- Download Intel#174; 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 3 March 2010 06:02, Dave Airlie airl...@gmail.com wrote: On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek hramr...@centrum.cz wrote: On 21 November 2009 05:27, Dave Airlie airl...@gmail.com 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? No we've never hooked it up but it could be made 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. 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. What about writing a drmfbset or something and have fbset call it when it detects a drm framebuffer and warn that it does not support drm framebuffers fully? That way people using fbset still get something and people who want exact control over the setup can use the new tool which uses whatever KMS interface is available already. Thanks Michal -- Download Intel#174; 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 3 March 2010 10:23, Dave Airlie airl...@gmail.com wrote: 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. What about writing a drmfbset or something and have fbset call it when it detects a drm framebuffer and warn that it does not support drm framebuffers fully? 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 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. You set the proper options on the proper layer - fonts in fbcons, resolution in fbdev or the driver (which sucks but so far nobody came up with a modesetting solution universal enough to work with all drivers), and some hardware-specific options in the driver as well. Still if most framebuffer drivers are converted to KMS there would not be interface discrepancies. KMS would be used to set resolution and fbdev to draw on the screen. So we'd need to add a bunch of KMS fb specifc ioctl like some of the other fbdev drivers do, and then a new fbset could tkae advantage of these. I'm not sure how much different to the current kms interface or how powerful we really need to make tihs interface though, and I feel kinda bad implementing it without some idea what users would want from it. 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. There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. 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. Thanks Michal -- Download Intel#174; 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 airl...@gmail.com 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? 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. Thanks Michal -- Download Intel#174; 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] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
2009/6/4 Krzysztof Helt krzysztof...@poczta.fm: On Wed, 3 Jun 2009 11:27:17 +0200 Michal Suchanek hramr...@centrum.cz wrote: Unfortunately I did not get to testing the patch yet. According to the description it is supposed to resolve some confusion over what pipe is enabled or not. X server reports the pipes connected as follows: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is off (II) intel(0): Display plane B is now disabled and connected to pipe A. (II) intel(0): Output VGA is connected to pipe none (II) intel(0): Output TMDS-1 is connected to pipe A (II) intel(0): Output TV is connected to pipe none However, I also get this warning before the outputs are listed: (WW) intel(0): Couldn't detect panel mode. Disabling panel Is this a configuration that would likely be affected by the issue fixed here or do I have a different problem? Frankly speaking, I don't know. Please describe your problem. The panel mode I suppose is LVDS (LCD panel directly connected to the chip) which is possible only in laptops and tablets or other computers where the LCD panel is integrated with the main unit (e.g. desk-lamp like Apple computers). All other computers which you connect the display by external cable (DVI/HDMI or VGA) does not work in the panel mode. This is a mac mini with single TMDS display only. Thanks Michal -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
2009/6/2 Andrew Morton a...@linux-foundation.org: On Sat, 30 May 2009 13:58:33 +0200 Krzysztof Helt krzysztof...@poczta.fm wrote: The intelfb driver sets color map depending on currently active pipe. However, if an LVDS display is attached (like in laptop) the active pipe variable is never set. The default value is PIPE_A and can be wrong. Set up the pipe variable during driver initialization after hardware state was read. Also, the detection of the active display (and hence the pipe) is wrong. The pipes are assigned to so called planes. Both pipes are always enabled on my laptop but only one plane is enabled (the plane A for the CRT or the plane B for the LVDS). Change active pipe detection code to take into account a status of the plane assigned to each pipe. The problem is visible in the 8 bpp mode if colors above 15 are used. The first 16 color entries are displayed correctly. The graphics chip description is here (G45 vol. 3): http://intellinuxgraphics.org/documentation.html Signed-off-by: Krzysztof Helt krzysztof...@wp.pl --- The second version of the fix to this problem. Now, it is much more sophisticated based on the knowledge gained from documentation available at http://intellinuxgraphics.org/. It does not change a default behaviour (assumed pipe A) for all cases except the case that only the plane assigned to the pipe B is active. It is enough to fix the issue for me. I queued this. Please test it. But it would great be Dean and/or Michal were to be able to test it, please. Thanks for the patch. Unfortunately I did not get to testing the patch yet. According to the description it is supposed to resolve some confusion over what pipe is enabled or not. X server reports the pipes connected as follows: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is off (II) intel(0): Display plane B is now disabled and connected to pipe A. (II) intel(0): Output VGA is connected to pipe none (II) intel(0): Output TMDS-1 is connected to pipe A (II) intel(0): Output TV is connected to pipe none However, I also get this warning before the outputs are listed: (WW) intel(0): Couldn't detect panel mode. Disabling panel Is this a configuration that would likely be affected by the issue fixed here or do I have a different problem? I am currently not using intelfb because last time I tried it produced even worse results than efifb (which does suffer from the wrong colors as well). Thanks Michal -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
2009/5/17 Krzysztof Helt krzysztof...@poczta.fm: On Sat, 16 May 2009 23:19:32 -0700 Andrew Morton a...@linux-foundation.org wrote: On Sun, 17 May 2009 08:17:43 +0200 Krzysztof Helt krzysztof...@poczta.fm wrote: This is not a regression. I have reproduced it in the 2.6.28 easily. hm, Dean's original report had This does not occur in kernel 2.6.29 -- I can see the Tasmanian devil in a penguin mask (Tuz) just fine and can view images, etc on the framebuffer. I can confirm that Tuz is also broken on my laptop (kernel v2.6.29). Maybe Dean had set different color depth (vga= parameter) for the older kernel? The dmesg output for the 2.6.29 would clear any doubts. For me this is broken ever since 2.6.26 on a Mac Mini with all of efifb/intelfb/vesafb but perhaps this is a different issue. I will try to rebuild 2.6.29 with intelfb and the patch to see if that makes a difference. Currently efifb does give correct geometry but wrong colours for me, the other framebuffers would also produce picture with wrong geometry with 2.6.26. Thanks Michal -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
