https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267606
--- Comment #44 from Yusuf Khan <[email protected]> ---
(In reply to Sergiy from comment #43)
Hmm...I believe I am too dumb to adequetely solve this problem unless I use gdb
on this but... I believe `NVSetModesInfo(pScrn->monitor->Modes,
pScrn->adjustFlags);` might need to be NVSetModesInfo(pScrn->modePool,
pScrn->adjustFlags);. Also the call to xf86SetModeCrtc should probably be
removed.
I am half asleep right now so I
1. Cant tell why(or maybe if??!?!) xf86ValidateModes() isnt setting the mode
names necessary for the modePool
2. Cant tell why we cant just pull a:
@@ -1975,14 +1975,8 @@ NVPreInit(ScrnInfoPtr pScrn, int flags)
if (i > 0)
VBESetModeParameters(pScrn, pNv->pVbe);
} else {
- i = xf86ValidateModes(pScrn, pScrn->monitor->Modes,
- pScrn->display->modes, clockRanges,
- NULL, 256, max_width,
- 512, 128, max_height,
- pScrn->display->virtualX,
- pScrn->display->virtualY,
- pNv->ScratchBufferStart,
- LOOKUP_BEST_REFRESH);
+ xf86ValidateModesSize(pScrn, pScrn->monitor->Modes,
+ max_width, max_height, 0);
+ i = 1;
}
if (i < 1 && pNv->FBDev) {
(personal modePool confusion)
---
If I was in front of an affected system , I would take my old patch, remove the
xf86SetModeCrtc bit to see if that fixes anything(probably wont), then revert
the changed to HEAD. After reverting to HEAD I would enable the FlatPanel and
DualHead flags separately to see if vesa stuff works(50/50 chance it does).
After that I would test the xf86ValidateModesSize patch above but I have no
idea if that will work at all. Maybe a bug should be added to the xserver bug
tracker for this issue, this probably affects other drivers(particularly i810).
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.