| View previous topic :: View next topic |
| Author |
Message |
gnychis
Veteran
Joined: 23 Mar 2005
Posts: 1004
Location: Pittsburgh, PA
|
 Posted: Sat Jun 25, 2005 7:24 pm Post subject: |
 |
|
i'll check the docs 
thanks so much for all your help |
|
| Back to top |
|
 |
gnychis
Veteran
Joined: 23 Mar 2005
Posts: 1004
Location: Pittsburgh, PA
|
| Posted: Sat Jun 25, 2005 7:50 pm Post subject: |
|
|
we're really close!
its running at 1680x1050@60 =-o
but its screwed up a little bit, the very top most line in the buffer is PERFECT, it stretches the screen perfectly... but all subsequent lines are too far right and wrap around to the left :\ Also, the screen flashes every 10 seconds or so.
also, my "nvidia" module doesn't work anymore for X11, on boot it says:
"can't load module nvidia"
"missing kernel or use mode driver nvidia"
and when i try "modprobe nvidia" i get:
"Fatal: Error inserting nvidia (/lib/modules/2.6.12-gentoo-r1/video/nvidia.ko): No such device"
any ideas?
(and i tried "emerge nvidia-kernel") |
|
| Back to top |
|
|
drefo
n00b
Joined: 28 May 2005
Posts: 46
|
| Posted: Sun Jun 26, 2005 12:14 am Post subject: |
|
|
Good news!
So now we at least know it's possible to do it.
Two things:
(1) Record as much information about the monitor specifications and the 1680x1050 mode
as you can possibly gather (try to set debug options for the nvidiafb in the source files).
(2) Try tweaking the mode with fbset ... see if that will work at all now.
This information may prove very useful if you have to go back to vesafb-tng ...
which sounds like it may be required ... we could enter it into the appropriate
structures by hand, even if we can't get vesafb-tng to probe your monitor with DDC.
As for the problems you've got with X, I'm not quite sure what's up ... it's possible there
is some interference between the Xorg nvidia module and the nvidia framebuffer support
in the kernel , although the first two errors (can't load module/missing kernel or user mode
driver) seem to suggest that the module just isn't there ... have you checked in the modules
directory for the new kernel to what the differences are with the old kernel?
I'ld also do a search to see if anyone has dealt with using the nvidiafb together with X.
It should be possible in principle, although there are clearly two pieces of software trying
to drive the same hardware.
Later ... |
|
| Back to top |
|
|
gnychis
Veteran
Joined: 23 Mar 2005
Posts: 1004
Location: Pittsburgh, PA
|
| Posted: Sun Jun 26, 2005 6:06 pm Post subject: |
|
|
ohhh! we are really close now
from another post, it turns out the nvidiafb seems to cause problems with the nvidia module, so people suggest not using nvidiafb for now and switching back to vesafb...
but!
I managed to use the demo modeline generator at the bottom of this page http://bisqwit.iki.fi/source/fbmodes.html#h2 ... and it gave me a working 1680x1050 mode for /etc/fb.modes !
so I added this to /etc/fb.modes:
| Code: |
mode "1680x1050-60"
# D: 132.272 MHz, H: 69.180 kHz, V: 60.000 Hz
geometry 1680 1050 1680 1050 8
timings 7560 50 50 50 50 132 3
vsync high
hsync high
endmode
|
and then i got a working 1680x1050 framebuffer which looks immaculate by doing:
| Code: |
fbset "1680x1050-60"
|
now all we have to do is hard code this into vesafb-tng, which i will definately need your help again...
So i'm going to post more information:
| Code: |
hedpe@monster ~ $ fbset -i
mode "1680x1050-60"
# D: 132.275MHz, H: 69.182 kHz, V: 60.001 Hz
geometry 1680 1050 1728 1050 8
timings 7560 50 50 50 50 132 3
hsync high
vsync high
accel true
rgba 8/0,8/0,8/0,0/0
endmode
Frame buffer device information:
Name : NV4
Address : 0xe0000000
Size : 268435456
Type : PACKED PIXELS
Visual : PSEUDOCOLOR
XPanStep : 8
YPanStep : 1
YWrapStep : 0
LineLength : 1728
MMIO Address : 0xf8000000
MMIO Size : 16777216
Accelerator : Unknown (46)
|
So, let me know what our next step should be |
|
| Back to top |
|
|
gnychis
Veteran
Joined: 23 Mar 2005
Posts: 1004
Location: Pittsburgh, PA
|
| Posted: Mon Jun 27, 2005 7:42 am Post subject: |
|
|
okay, update, i added the following lines of code in vesafb-tng.c, right in the function vesafb_set_par(), right after line 253
| Code: |
info->var.xres = 1680;
info->var.yres = 1050;
info->var.right_margin = 50;
info->var.left_margin = 50;
info->var.upper_margin = 50;
info->var.lower_margin = 50;
info->var.vsync_len = 3;
info->var.hsync_len = 132;
|
the result is the following:
| Code: |
monster video # fbset -i
mode "1680x1050-29"
# D: 65.003 MHz, H: 33.997 kHz, V: 29.486 Hz
geometry 1680 1050 1024 1536 8
timings 15384 50 50 50 50 132 3
rgba 8/0,8/0,8/0,0/0
endmode
Frame buffer device information:
Name : VESA VGA
Address : 0xe0000000
Size : 1572864
Type : PACKED PIXELS
Visual : PSEUDOCOLOR
XPanStep : 0
YPanStep : 1
YWrapStep : 0
LineLength : 1024
Accelerator : No
|
the vsync is low, the xpan step is off, the accelerator is off, line length is off, and a few other things are wrong too.
Even though it says 1680x1050 ... when the frame buffer is shown during boot, it looks a lot smaller than 1680x1050
so maybe we're not setting the .xres and .yres early enough? Or are the frequencies and line length the problems?
Thanks!
George |
|
| Back to top |
|
|
drefo
n00b
Joined: 28 May 2005
Posts: 46
|
| Posted: Mon Jun 27, 2005 6:40 pm Post subject: |
|
|
Excellent! I was just going to suggest doing more or less the same thing. I think the main problem
is probably the frequencies. Remember that your monitor was probed with DDC before,
so the nvidiafb was able to set that information properly in the monitor specs. If you just find out
where the monitor specs are stored and enter the same values that nvidiafb got, I think you might
be in business.
Another way might be to use the gtf option to enter the timings ... I haven't figured out
completely how that's supposed to work yet.
For the xpan, accelerator and linelength, you may be able to fix those by searching for
the variables that are being printed out in those messages and setting them before fb_set_par
writes the mode to hardware.
Does fbset still give the EINVAL error if you try to modify the mode now?
Update:
The monitor specs are stored in the substructure info->monspecs, and it looks like
the gtf code can probably be used to initialize them to the values you need. You
would set noedid and gtf again in the kernel options, then the code should fall
through to gtf to calculate the mode timings.
The relevant function is fb_get_mode() defined in fbmon.c, and it looks like you
could initialize info->monspecs right at the beginning of that function.
The comments mention that you may have to define some of the variables
by hand, and that the code requires a valid info->monspecs, or it uses
safe values ... so it may require a bit of playing before it works, but I bet
it will eventually work.
Some of the monitor parameters can be passed in as kernel options ... the
documentation specifies that these three parameters will override edid
and everything else, if you set them:
| Code: |
maxhf:n Maximum horizontal frequency (in kHz).
maxvf:n Maximum vertical frequency (in Hz).
maxclk:n Maximum pixel clock (in MHz).
|
Note the arguments to fb_get_mode() are of type *fb_var_screeinfo, and
*fb_info:
| Code: |
int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var, struct fb_info *info) {
...
}
|
The full structure fb_var_screeninfo is defined in <linux/fb.h:155>:
| Code: |
struct fb_var_screeninfo {
__u32 xres; /* visible resolution */
__u32 yres;
__u32 xres_virtual; /* virtual resolution */
__u32 yres_virtual;
__u32 xoffset; /* offset from virtual to visible */
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* != 0 Graylevels instead of colors */
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
__u32 nonstd; /* != 0 Non standard pixel format */
__u32 activate; /* see FB_ACTIVATE_* */
__u32 height; /* height of picture in mm */
__u32 width; /* width of picture in mm */
__u32 accel_flags; /* (OBSOLETE) see fb_info.flags */
/* Timing: All values in pixclocks, except pixclock (of course) */
__u32 pixclock; /* pixel clock in ps (pico seconds) */
__u32 left_margin; /* time from sync to picture */
__u32 right_margin; /* time from picture to sync */
__u32 upper_margin; /* time from sync to picture */
__u32 lower_margin;
__u32 hsync_len; /* length of horizontal sync */
__u32 vsync_len; /* length of vertical sync */
__u32 sync; /* see FB_SYNC_* */
__u32 vmode; /* see FB_VMODE_* */
__u32 rotate; /* angle we rotate counter clockwise */
__u32 reserved[5]; /* Reserved for future compatibility */
};
|
so you can initialize all of these in var at the beginning of fb_get_mode()..
The full structure fb_info is also defined in fb.h:710:
| Code: |
struct fb_info {
int node;
int flags;
struct fb_var_screeninfo var; /* Current var */
struct fb_fix_screeninfo fix; /* Current fix */
struct fb_monspecs monspecs; /* Current Monitor specs */
struct work_struct queue; /* Framebuffer event queue */
struct fb_pixmap pixmap; /* Image hardware mapper */
struct fb_pixmap sprite; /* Cursor hardware mapper */
struct fb_cmap cmap; /* Current cmap */
struct list_head modelist; /* mode list */
struct fb_videomode *mode; /* current mode */
struct fb_ops *fbops;
struct device *device;
struct class_device *class_device; /* sysfs per device attrs */
#ifdef CONFIG_FB_TILEBLITTING
struct fb_tile_ops *tileops; /* Tile Blitting */
#endif
char __iomem *screen_base; /* Virtual address */
unsigned long screen_size; /* Amount of ioremapped VRAM or 0 */
void *pseudo_palette; /* Fake palette of 16 colors */
#define FBINFO_STATE_RUNNING 0
#define FBINFO_STATE_SUSPENDED 1
u32 state; /* Hardware state i.e suspend */
void *fbcon_par; /* fbcon use-only private area */
/* From here on everything is device dependent */
void *par;
};
|
For the accel part, you can set the value for flags using a bitwise and: you can find
the symbols you need for that listed right below fb.h:679
| Code: |
/* FBINFO_* = fb_info.flags bit flags */
#define FBINFO_MODULE 0x0001 /* Low-level driver is a module */
#define FBINFO_HWACCEL_DISABLED 0x0002
|
And the substructure fb_monspecs is also defined there (fb.h:412):
| Code: |
struct fb_monspecs {
struct fb_chroma chroma;
struct fb_videomode *modedb; /* mode database */
__u8 manufacturer[4]; /* Manufacturer */
__u8 monitor[14]; /* Monitor String */
__u8 serial_no[14]; /* Serial Number */
__u8 ascii[14]; /* ? */
__u32 modedb_len; /* mode database length */
__u32 model; /* Monitor Model */
__u32 serial; /* Serial Number - Integer */
__u32 year; /* Year manufactured */
__u32 week; /* Week Manufactured */
__u32 hfmin; /* hfreq lower limit (Hz) */
__u32 hfmax; /* hfreq upper limit (Hz) */
__u32 dclkmin; /* pixelclock lower limit (Hz) */
__u32 dclkmax; /* pixelclock upper limit (Hz) */
__u16 input; /* display type - see FB_DISP_* */
__u16 dpms; /* DPMS support - see FB_DPMS_ */
__u16 signal; /* Signal Type - see FB_SIGNAL_* */
__u16 vfmin; /* vfreq lower limit (Hz) */
__u16 vfmax; /* vfreq upper limit (Hz) */
__u16 gamma; /* Gamma - in fractions of 100 */
__u16 gtf : 1; /* supports GTF */
__u16 misc; /* Misc flags - see FB_MISC_* */
__u8 version; /* EDID version... */
__u8 revision; /* ...and revision */
__u8 max_x; /* Maximum horizontal size (cm) */
__u8 max_y; /* Maximum vertical size (cm) */
};
|
So, although this is a very ugly hack, I think you can just enter the necessary definitions
at the beginning of fb_get_mode, if you use the noedid and gtf options. You won't
need to define absolutely everything, of course, and you can print out the values that
are already set by adding printk's at the beginning of fb_get_mode. That's probably
a worthwhile exercise in any case.
I think we can begin to see the light at the end of the tunnel by now  |
|
| Back to top |
|
|
drefo
n00b
Joined: 28 May 2005
Posts: 46
|
| Posted: Mon Jun 27, 2005 10:09 pm Post subject: |
|
|
For setting vsync and hsync to high, you want to do a bitwise and of
the appropriate flags with var->sync;
The symbols for the sync flags are also in fb.h:184
| Code: |
#define FB_SYNC_HOR_HIGH_ACT 1 /* horizontal sync high active */
#define FB_SYNC_VERT_HIGH_ACT 2 /* vertical sync high active */
...
|
|
|
| Back to top |
|
|
drefo
n00b
Joined: 28 May 2005
Posts: 46
|
| Posted: Mon Jun 27, 2005 10:27 pm Post subject: |
|
|
Sorry ... substitute bitwise OR everywhere I said bitwise AND. Oops  |
|
| Back to top |
|
|
gnychis
Veteran
Joined: 23 Mar 2005
Posts: 1004
Location: Pittsburgh, PA
|
| Posted: Tue Jun 28, 2005 7:07 pm Post subject: |
|
|
just a quick update while i work on it:
| Code: |
hedpe@monster ~ $ fbset -i
mode "1680x1050-29"
# D: 64.033 MHz, H: 33.490 kHz, V: 29.046 Hz
geometry 1680 1050 1024 1536 8
timings 15617 50 50 50 50 132 3
hsync high
vsync high
rgba 8/0,8/0,8/0,0/0
endmode
Frame buffer device information:
Name : VESA VGA
Address : 0xe0000000
Size : 1572864
Type : PACKED PIXELS
Visual : PSEUDOCOLOR
XPanStep : 0
YPanStep : 1
YWrapStep : 0
LineLength : 1024
Accelerator : No
|
I got the YPanStep correct... i can't seem to find the XPanStep, and i'm not sure how we are going to set the accelerator either
I got the sync's correct |
|
| Back to top |
|
|
drefo
n00b
Joined: 28 May 2005
Posts: 46
|
| Posted: Tue Jun 28, 2005 7:58 pm Post subject: |
|
|
| hedpe wrote: | just a quick update while i work on it:
I got the YPanStep correct... i can't seem to find the XPanStep, and i'm not sure how we are going to set the accelerator either
I got the sync's correct |
It's getting there ... I'm not certain whether the hardware acceleration will work or not, as it may need
special code, such as nvidiafb probably has, to initialize the chipset properly, but it's definitely worth a try.
I think you just need to make sure that bit 1 in fb_info.flags is not set (numbering
bits starting from 0, 0 being the least significant bit).
So if flags is initially 0, you would do something like this:
| Code: |
flags |= FBINFO_HWACCEL_COPYAREA;
flags |= FBINFO_HWACCEL_FILLRECT;
...
flags |= FBINFO_HWACCEL_XPAN;
flags |= FBINFO_HWACCEL_YPAN;
|
Both xpanstep and ypanstep seem to be part of fb_info.fix, and fix is of type fb_fix_screeninfo, see
fb.h:136 for the definition.
These are supposed to work if you have hardware acceleration enabled (ie, the FBINFO_HWACCEL_XPAN and
_YPAN are set in fb_info.flags.
Just make sure that at the end of setting all the flags, bit 1 is equal to zero, and I think you should have hardware
acceleration if it's at all possible.
Update:
LineLength appears to be in fb_fix_screeninfo, too, so I guess you can set that to 1728. |
|
| Back to top |
|
|
drefo
n00b
Joined: 28 May 2005
Posts: 46
|
| Posted: Tue Jun 28, 2005 8:58 pm Post subject: |
|
|
One more thing: in vesafb_set_par(), at line 253, you could probably have started with the new
default mode entry we defined (it seems like a long time ago now), in vesa_modes[], by doing something
like this:
| Code: |
i=34;
mode = &vesa_modes[i];
|
Of course, then you'd have to write a function equivalent to vesafb_find_vbe_mode(...)
to initialize info, and that's pretty much what you're doing now anyway.
But this might be a way to clean up the code a bit after it's all done. It might be a lot easier if
it were possible to pass most of this stuff we're setting up now right in as kernel boot
time options. Something like a specify everything by hand option to video="" could be
written ... warning people to use it at their own risk, of course
Update:
Oops ...
I see that that's not quite the way it works, since vesafb_find_vbe_mode() is just
a simple table lookup. I wonder what mode is equal to when you first hit fb_set_par?
Clearly it can't be NULL, because the function should return with EINVAL in that case.
Weird.
But I suppose somehow one of the vbe_modes must be found by the table lookup,
and then you are just reinitializing the info structure ... that should be no problem in principle,
but it probably explains why you have some weird values set, like linelength 1024.
In any case, if this ends up working, it seems like we probably want to eventually move the initialization
of info outside of vesafb_set_par(), or at least disable it after the first call of the function, since if vesafb_set_par()
is ever called again by any code (such as fbset, for example) and the info you want is hard coded into the function
itself, then it will always only set the mode you've hard-coded. What we've done is apparently not consistent
with fb_ops.fb_set_par being an invariant framebuffer operation.
But you do find the following a little further on in vesafb_set_par():
| Code: |
/* the VBE mode number is valid only the first time the mode is set */
if (vbemode)
vbemode = 0;
|
So in a sense, the problem was always there |
|
| Back to top |
|
|
gnychis
Veteran
Joined: 23 Mar 2005
Posts: 1004
Location: Pittsburgh, PA
|
| Posted: Wed Jun 29, 2005 5:13 pm Post subject: |
|
|
I'm still working on it, but check out the e-mail we got from spock (the developer of vesafb-tng):
| Code: |
Hi,
> Thanks for all the info. Is it possible, or a bad idea, to modify your
> code and "hard-code" a 1680x1050 mode into vesafb-tng? Basically,
> manually set the parameters?
Nope, this is not possible. Believe me, if it could be done in any sane
way, there'd a how-to about it on the vesafb-tng pages :)
|
I'm not sure what to make of it |
|
| Back to top |
|
|
drefo
n00b
Joined: 28 May 2005
Posts: 46
|
| Posted: Wed Jun 29, 2005 6:11 pm Post subject: |
|
|
It seems to me Spock has a good sense of humour ... he says there's no
sane way of doing it, but of course, that doesn't really rule out that
there may be an insane way of doing it
It's clear that the driver is set up very carefully to check for reasonable existing modes
from all of the hardware, and really, the hardware should tell the driver what modes
are available. That would be sane behaviour. We're basically short-circuiting all of that
careful checking, which, you have to admit, is pretty insane. You wouldn't want to let
a driver modified in that way loose on an unsuspecting person, since in principle (it's
probably very unlikely in practice) it could fry their graphics card or monitor, if a bad
mistake were made.
The underlying problem you're facing is really that DDC fails with the vesafb-tng, so you
have to use the nvidiafb ... but that isn't a viable solution, since nvidiafb fails to work together
with X. I think that the sane solution would be to fix the problem with nvidiafb and X.
You could also try to see if DDC can be made to work with vesafb-tng ... that's a direction
we haven't tried. We could study the nvidiafb code, and maybe, just possibly, find a simple way
to get vesafb-tng to use DDC with your monitor. If the modifications to vesafb-tng to make
that work are too extensive, though, it would be better to use nvidiafb in the first place.
If you get tired of working on this, it might be sensible just to wait for a while
and see if the problems with nvidiafb are eventually worked out. You could just
live without a framebuffer if you use the system mostly under X.
For my part, I've had a lot of fun reading the driver code, and I learned a lot, even
if it is pretty insane. 
PS: Did Spock have anything else to say that might help? |
|
| Back to top |
|
|
drefo
n00b
Joined: 28 May 2005
Posts: 46
|
| Posted: Wed Jun 29, 2005 6:43 pm Post subject: |
|
|
Looking at nvidia/nv_setup.c, you can see that the I2C busses are set up in
| Code: |
void NVCommonSetup(struct fb_info *info)
|
The edid probe is also carried out in this function.
So it's clear the code that initializes the I2C busses would have to be executed
in order to get DDC working. I think that means already that it won't be sensible to
do it in vesafb-tng. But you could setup some DPRINTK's at the end of NVCommonSetup,
so as to print out all of the data which is in info->monspecs. Then you'll know for sure
what has to be entered into the same structure in vesafb-tng, which might save
you a lot of screwing around ... |
|
| Back to top |
|
|
drefo
n00b
Joined: 28 May 2005
Posts: 46
|
| Posted: Wed Jun 29, 2005 8:56 pm Post subject: |
|
|
Here's some code to print monspecs out ... it's very simple, of course, but it
may save you some typing:
At the top of nv_setup.c put this:
| Code: |
#define DEBUG 1 /* #undef DEBUG to disable printing */
#ifdef DEBUG
# define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: " fmt, __FUNCTION__ , ## args)
#else
# define DPRINTK(fmt, args...)
#endif
|
Then at the bottom, following
| Code: |
if (monA) {
info->monspecs = *monA;
|
put this in:
| Code: |
if(! info->monspecs) { DPRINTK("No Monitor Specs Found!\n"); }
else {
DPRINTK("Monitor Specs from DDC\n");
DPRINTK("chroma\n");
DPRINTK("\tchroma.redx: %d\n", info->monspecs->chroma->redx);
DPRINTK("\tchroma.greenx: %d\n", info->monspecs->chroma->greenx);
DPRINTK("\tchroma.bluex: %d\n", info->monspecs->chroma->bluex);
DPRINTK("\tchroma.whitex: %d\n", info->monspecs->chroma->whitex);
DPRINTK("\tchroma.redy: %d\n", info->monspecs->chroma->redy);
DPRINTK("\tchroma.greenyy: %d\n", info->monspecs->chroma->greeny);
DPRINTK("\tchroma.bluey: %d\n", info->monspecs->chroma->blueyy);
DPRINTK("\tchroma.whitey: %d\n", info->monspecs->chroma->whitey);
DPRINTK("Video Mode Database\n");
if(info->monspecs->modedb_len > 0) {
DPRINTK("Found %d modes\n", info->monspecs->modedb_len);
for (i=0; i<info->monspecs->modedb_len; i++) {
DPRINTK("mode: %d\n", i);
DPRINTK("\tname: %s\n", info->monspecs->modedb[i].name);
DPRINTK("\trefresh: %d\n", info->monspecs->modedb[i].refresh);
DPRINTK("\txres: %d\n", info->monspecs->modedb[i].xres);
DPRINTK("\tyres: %d\n", info->monspecs->modedb[i].yres);
DPRINTK("\tpixclock: %d\n", info->monspecs->modedb[i].pixclock);
DPRINTK("\tleft_margin: %d\n", info->monspecs->modedb[i].left_margin);
DPRINTK("\tright_margin: %d\n", info->monspecs->modedb[i].right_margin);
DPRINTK("\tupper_margin: %d\n", info->monspecs->modedb[i].upper_margin);
DPRINTK("\tlower_margin: %d\n", info->monspecs->modedb[i].lower_margin);
DPRINTK("\thsync_len: %d\n", info->monspecs->modedb[i].hsync_len);
DPRINTK("\tvsync_len: %d\n", info->monspecs->modedb[i].vsync_len);
DPRINTK("\tsync: %d\n", info->monspecs->modedb[i].sync);
DPRINTK("\tvmode: %d\n", info->monspecs->modedb[i].vmode);
DPRINTK("\tflag: %d\n", info->monspecs->modedb[i].flag);
}
} else {
DPRINTK("No modes found: %d\n", info->monspecs->modedb_len);
}
DPRINTK("Manufacturer: %s\n", info->monspecs->manufacturer);
DPRINTK("Monitor: %s\n", info->monspecs->monitor);
DPRINTK("Serial Number: %s\n", info->monspecs->serial_number);
DPRINTK("Extra: %s\n", info->monspecs->ascii);
DPRINTK("Video Mode Database Length: %d\n", info->monspecs->modedb_len);
DPRINTK("Model: %d\n", info->monspecs->model);
DPRINTK("Serial: %d\n", info->monspecs->serial);
DPRINTK("Year Manufactured: %d\n", info->monspecs->year);
DPRINTK("Week Manufactured: %d\n", info->monspecs->week);
DPRINTK("hfreq lower limit (Hz): %d\n", info->monspecs->hfmin);
DPRINTK("hfreq upper limit (Hz): %d\n", info->monspecs->hfmax);
DPRINTK("pixelclock lower limit (Hz): %d\n", info->monspecs->dclkmin);
DPRINTK("pixelclock upper limit (Hz): %d\n", info->monspecs->dclkmax);
DPRINTK("display type (see FB_DISP_): %d\n", info->monspecs->input);
DPRINTK("dpms support (see FB_DPMS_): %d\n", info->monspecs->dpms);
DPRINTK("signal type (see FB_SIGNAL_): %d\n", info->monspecs->dpms);
DPRINTK("vfreq lower limit (Hz): %d\n", info->monspecs->vfmin);
DPRINTK("vfreq upper limit (Hz): %d\n", info->monspecs->vfmax);
DPRINTK("gamma (fractions of 100): %d\n", info->monspecs->gamma);
DPRINTK("supports gtf%d\n", info->monspecs->gtf);
DPRINTK("miscellaneous flags (See FB_MISC_): %d\n", info->monspecs->misc);
DPRINTK("EDID version: %d\n", info->monspecs->version);
DPRINTK("EDID revision: %d\n", info->monspecs->revision);
DPRINTK("Maximum horizontal size (cm): %d\n", info->monspecs->max_x);
DPRINTK("Maximum horizontal size (cm): %d\n", info->monspecs->max_y);
}
|
Last edited by drefo on Thu Jun 30, 2005 3:27 am; edited 2 times in total |
|
| Back to top |
|
|
gnychis
Veteran
Joined: 23 Mar 2005
Posts: 1004
Location: Pittsburgh, PA
|
| Posted: Thu Jun 30, 2005 3:21 am Post subject: |
|
|
drefo, thanks so much for all your help, I am keeping hope alive
I am going to put that output in when I get home tonight and I will let you know how it goes.
My only concern is, when nvidiafb loads, it loads 1024x768... but I was able to manually put the mode into /etc/fb.modes
I think I have to get nvidiafb to start up with 1680x1050 before the output will be useful
So I will work on that first also
Thanks bud!
- George |
|
| Back to top |
|
|
drefo
n00b
Joined: 28 May 2005
Posts: 46
|
| Posted: Thu Jun 30, 2005 3:34 am Post subject: |
|
|
My pleasure, George.
I think most of monitor specs should be pretty much the same, no matter what the startup mode is,
and if there's a 1680x1050 mode known to the monitor at all, I think it should be printed out
in one of the modedb entries inside info->monspecs. Of course, you'll need to change it a bit
to get to the working mode you finally created with fbset. But hopefully it will become clear what
you need to change and what you don't need to.
Cheers!
David |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
