Re: [XFree86] Dynamically change X server resolution
I am new to Xfree86 development. Is it possible to implement an X server that can dynamically changing the physical resolution (resolution in the framebuffer, not virtual). Please comment. Thanks. You mean the Xvm video mode changing extensions? -- -- Lewin A.R.W. Edwards Work: http://www.digi-frame.com/ Personal: http://www.larwe.com/ ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
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
[XFree86] Geode and doublescanned modes
Hi all, I've been trying for some time now to get low resolution doublescanned video modes working with XFree86 4.xxx. (currently 4.2.99.3). I'm playing back 352x288 MPEG video on this platform and it just isn't frisky enough to upscale to 640x480. Ideally I'd like to get 400x300 working. I found some old messages from the xpert list talking about this issue, but I can't fathom (a) if anyone got it to actually /work/, and (b) what is required. So I guess the bottom line is: does anyone know if there exists a nsc_drv.o that can actually use doublescanned modes? I've experimented with manually-created Modelines, I have a Virtual 1024 768 in my XF86Config to get around the must be 480 pixels tall whining from the driver, and I've asked in a couple of relevant newsgroups, with no useful answer. -- -- Lewin A.R.W. Edwards Work: http://www.digi-frame.com/ Personal: http://www.larwe.com/ ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [Xpert]People working on Geode/CS5530 in XFree86 4.x?
National produce Linux drivers for the Geode/CS5530 for both XFree86 4 and 3.3.6, as well as native mode audio drivers (rather than SB emulation that you note on your web page). My understanding is that they are only available to companies NDA with National Semi. Interesting - I wondered where NS's drivers went (they used to be on a publicly-accessible web page; I should have downloaded them while I had a chance). So I guess I'm on my own then. I don't want to get the legal behemoth lumbering on establishing a relationship with NS, because we don't buy anything directly from them and we have no intention of tying ourselves to their hardware - at the moment it's cheap and does what we want, but we can and will switch to other SBC architectures as our needs vary. Thanks for the info. I guess I will try some simple hacks on the mediagx driver to at least get 4.x working, and I'll release a patch if I do get it working. -- Lewin A.R.W. Edwards Embedded Engineer, Digi-Frame Inc. Work: http://www.digi-frame.com/ Tel (914) 937-4090 9am-6:30pm M-F ET Personal: http://www.larwe.com/ http://www.zws.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rotated display under Linux?
Option Rotate CW Option Rotate CCW Ugh, I haven't tried this stuff in a long time. It looks like somebody broke all of this stuff. I doubt the problems are specific How come this is handled so strangely? My daily bread is a series of embedded systems with inbuilt gravity sensor that rotate the onscreen display dynamically (realtime) when the user rotates the housing. We don't use the chipset rotation features. We keep the chipset believing it is working with (say) a 640x480 display, and the application layer believes it is working with a 480x640 display. The GDI layer does the rotation and translation of coordinates, maintaining use of hardware acceleration features where available (including hardware cursor...). Sounds like the current X code uses a single piece of generic rotation code and bumps every chipset down to an unaccelerated mode using that rotation code. -- Lewin A.R.W. Edwards Embedded Engineer, Digi-Frame Inc. Work: http://www.digi-frame.com/ Tel (914) 937-4090 9am-6:30pm M-F ET Personal: http://www.larwe.com/ http://www.zws.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Rotated display under Linux?
Hi Mark, We don't use the chipset rotation features. We keep the chipset believing it is working with (say) a 640x480 display, and the application layer believes it is working with a 480x640 display. The GDI layer does the rotation and translation of coordinates, maintaining use of hardware acceleration features where available (including hardware cursor...). That's because rotating X-rendering correctly is an ominous task. X11 is a pixel-perfect specification. Just rotating the coordinates on lines and polygons won't render them correctly. None of this Can you explain this further? At the moment I have a system - running X actually - where I am emulating my older proprietary systems inside a frame buffer. Eventually I would have gotten around to looking at X's rotation possibilities anyway; I knew of it theoretically but have never tried to use it. Bear in mind that I know nothing about the internals of how things are represented in X. But the first part I don't understand is why rotating the coordinates of lines and polygons will not yield a correct result. A rectangle 100x25 pixels in size, 100 pixels right of the origin and 50 pixels below it, is described completely regardless of the geometry of the screen (assuming a Windows-convention origin, not an OS/2 PM-convention origin, of course :) My understanding of how it would work is that it would abstract the rotation at the same level I abstract it - i.e. the client app would be unaware of the rotation and would only be aware of the fact that the screen's pixel dimensions are a bit strange. As far as the client is concerned there is no rotation; the dimensions and sign-directions of the display surface exactly match that of the physical display output. The client renders at (say) 480x640; the user sees 480x640. The fact that there is a rotation operation is purely a hardware issue related to the order in which the display controller DMAs pixels out of RAM; it's just an issue of internal frame storage. Where am I going wrong in my understanding? And is this a question of rigorous standards compliance, or one of basic functional failure that will be obvious to the user? (Oh, and in case this is not clear: I'm not at all being argumentative or implying that any XFree code is bad, I'm just trying to see why it is impossible to implement an efficiency improvement). OT-PS: Pity you guys (NVidia) wouldn't sell us LCD controllers when we asked ;) but I'm very interested to try your PDA-chip with integral MIPS micro... ;) (or was that Neomagic? Darn N-names :) If there's a Linux port and an X server, I'm a happy monkey. -- Lewin A.R.W. Edwards Embedded Engineer, Digi-Frame Inc. Work: http://www.digi-frame.com/ Tel (914) 937-4090 9am-6:30pm M-F ET Personal: http://www.larwe.com/ http://www.zws.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
