Patch-for mode bug in NSC driver.
(Alex, this is just an FYI in case you're interested :)
Okay, I think I'm there.
There appears to be a fairly serious bug in the function
gfx_is_display_mode_supported() in
xc/programs/Xserver/hw/xfree86/drivers/nsc/gfx/disp_gu1.c from
yesterday's CVS.
Not being familiar with XFree86 internals, I'm not sure if this is
/actually/ a bug in the function itself, or in the overlying code, or in
the display modes table in
xc/programs/Xserver/hw/xfree86/drivers/nsc/gfx/gfx_disp.c. I just fixed
the symptoms.
The problem is that the aforementioned table contains actual pixel
scanline heights (e.g. 320 x 240 has a vertical size of 240), whereas
the input scanline height supplied to the function will be 480 (IOW beam
scanlines, not pixel scanlines). This means that
gfx_is_display_mode_supported will never find any mode that's supposed
to be scandoubled; hence, these modes are currently totally broken on
Geode.
I modified the above function to check if the current mode's flags
indicate doublescanning, and if so it generates a bogus doubled
scanheight for comparison purposes.
The following three patches fix this bug and alter a couple of minima,
thereby enabling lo-res video modes on the Geode platform:
Note! Xv support is still at least partly broken in these modes, I
believe.
--- Begin patch for disp_gu1.c
130a131,135
/*
* Bugfix to gfx_is_mode_supported to fix problems with doublescan
modes
* Lewin A.R.W. Edwards [EMAIL PROTECTED]
*/
839d843
840a845,850
int tmp_yres;
tmp_yres = yres;
if (DisplayParams[mode].flags GFX_MODE_LINE_DOUBLE)
tmp_yres = tmp_yres / 2;
842,843c852,853
(DisplayParams[mode].vactive == (unsigned short)yres)
(DisplayParams[mode].flags hz_flag)
---
(DisplayParams[mode].vactive == (unsigned short)tmp_yres)
(DisplayParams[mode].flags hz_flag)
850a861
878a890
--- Begin patch for nsc_gx1_driver.c
150a151,155
/*
* Minor patches to allow support of low-res video modes
* Lewin A.R.W. Edwards [EMAIL PROTECTED]
*/
475c480
{ NULL, 25175, 135000, 0, FALSE, TRUE, 1, 1, 0 };
---
{ NULL, 1, 135000, 0, FALSE, TRUE, 1, 1, 0 };
937c942
minHeight = 480;
---
minHeight = 200;
1850c1855,1856
if (MemIndex == -1)/* no match */
---
if (MemIndex == -1)/* no match */
2363a2370
--- Begin patch for nsc_gx2_driver.c
145a146,150
/*
* Minor patches to allow support of low-res video modes
* Lewin A.R.W. Edwards [EMAIL PROTECTED]
*/
474c479
{ NULL, 25175, 229500, 0, FALSE, TRUE, 1, 1, 0 };
---
{ NULL, 1, 229500, 0, FALSE, TRUE, 1, 1, 0 };
911c916
minHeight = 480;
---
minHeight = 200;
--
-- Lewin A.R.W. Edwards
Work: http://www.digi-frame.com/
Personal: http://www.larwe.com/
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
bitblt operation in frame buffer
Hi, I want to transfer a block of image data from source offset in off_screen to a specified rectangular area in on_screen area. If the source image is saved with rectangular trajectory, I can set some registers such as SRC_Y_X, DR_MIX, DP_CNTL,DST_Y_X and DST_HEIGHT_WIDTH to transfer pixels from SRC_Y_X to DST_Y_X. However, in order to save memory space, I want to save the image data in frame buffer with lineal trajectory instead of a rectangular area. Can I still transfer the image pixels by just setting some registers? If I can, which register is for src offset? If cannot, a possible value of register DP_SRC_SOURCE is hostdata,lineal trajectory, and I guess it means that I can set some register value to source address, in which image data is saved in continuous address in host memory. But what is this register? I had a tough time to find it. :( Thank you so~~~ much, jing ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
about change 614. Restore the Alt/Meta mappings for pc104/pc105 ...
[Feel free to cc me since I'm not currently subscribed to the list.]
Hello,
I would like to ask why the following change was made to the
pc symbols file. Why should we rather have Super on Win
keys in 4.3, than Meta as in 4.2? Additionally xkb doesn't
seem to want to have both Alt and Meta on the some modifier
currently afaict.
Thanks for any light on the matter,
Jens
614. Restore the Alt/Meta mappings for pc104/pc105 keyboards in the
multi-layout maps (David Dawes).
===
RCS file: /xf86/anoncvs/cvs/xc/programs/xkbcomp/symbols/pc/pc,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- xc/programs/xkbcomp/symbols/pc/pc 2002/12/02 11:11:49 1.3
+++ xc/programs/xkbcomp/symbols/pc/pc 2002/12/11 03:40:13 1.4
@@ -1,6 +1,6 @@
//
-// $XFree86: xc/programs/xkbcomp/symbols/pc/pc,v 1.2 2002/11/22 04:03:28 dawes Exp $
+// $XFree86: xc/programs/xkbcomp/symbols/pc/pc,v 1.3 2002/12/02 11:11:49 alanh Exp $
partial hidden alphanumeric_keys modifier_keys
xkb_symbols basic {
@@ -215,15 +215,15 @@ xkb_symbols pc102 {
default
xkb_symbols pc104 {
include pc/pc(basic)
-key LALT { [ Alt_L ] };
-key RALT { [ Alt_R ] };
-key LWIN { [ Meta_L ] };
-key RWIN { [ Multi_key ] };
-key MENU { [ Menu] };
+key LALT { [ Alt_L, Meta_L ] };
+key RALT { [ Alt_R, Meta_R ] };
+key LWIN { [ Super_L ] };
+key RWIN { [ Super_R ] };
+key MENU { [ Menu] };
// modifier mappings
-modifier_map Mod1 { Alt_L, Alt_R };
-modifier_map Mod4 { Meta_L, Meta_R };
+modifier_map Mod1 { Alt_L, Alt_R, Meta_L, Meta_R };
+modifier_map Mod4 { Super_L, Super_R };
};
// defintion which includes both the Windows95 keyboards _and_
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting David Dawes [EMAIL PROTECTED]: On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). I think there is another problem, MouseKeys also stoped working, the default bindings to select buttons don't work anymore: / - select button1 * - select button2 - - select button3 + - double click setxkbmap -print | xkbcomp -w 10 - :0 seens to show the possible problems. Keypad numbers are repeating, and mouse keys also working for the numeric bindings. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
