REPLY REQUIRED: Confirm subscription to group Integrated Solutions
Title: domeus system message Hello [EMAIL PROTECTED], thanks for your interest in the group Integrated Solutions ([EMAIL PROTECTED]) If you would like to accept this invitation, please return this eMail by clicking on reply or subscribe via the Web. Subscribe If you are not interested in joining, please ignore this eMail and you will receive no further eMails from us. The group owner sends the following welcome message: - Welcome to Integrated Solutions! Our systems and programs can help you to successfully optimize your professional potential in a changing world. To be able to progress efficiently in any area today, we promote new smart working and learning systems through new techniques, tools and methodologies (TTMs) in key Smart Learning Areas: Knowledge Management, Change Management, Quantitative Learning, Qualitative Learning, Skill Management and Business Intelligence. For more information visit our web www.amjsmartlearning.com [EMAIL PROTECTED] - If you would like to use the full range of features, just log in at http://uk.domeus.com using the following log-in information: username: [EMAIL PROTECTED] password: cebefeb4 If your eMail address has been added to this list without your consent and you do not wish to receive eMails from Domeus, please forward this message to: [EMAIL PROTECTED] Best regards, Your Domeus Team
Re: Getting Dual Independent Heads to work on Debian(sid) on iBook
On Fri, 2003-06-13 at 22:01, Andreakis, Dean (MED) wrote: > > I went ahead and commented out the dri section and the Load "dri", Load > "GLcore" and Load "glx" lines in the "Module" section of XF86Config-4 to > try and prevent the DRI drivers from loading but I still see the same > messages in the XF86 log file. Maybe I need to do something else to stop > DRI from trying to load... Don't worry about the DRI, it shouldn't have any influence on your problem. It gets disabled with multihead anyway. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Getting Dual Independent Heads to work on Debian(sid) on iBook
It's not the DRI per se... it's the radeon memory manager. it attempts to statically allocate offscreen memory for use by the DRI, pixmaps, etc. It has no effect on modes, so you can safely ignore it. Alex --- "Andreakis, Dean (MED)" <[EMAIL PROTECTED]> wrote: > Alex, > > I went ahead and commented out the dri section and the Load "dri", > Load > "GLcore" and Load "glx" lines in the "Module" section of XF86Config-4 > to > try and prevent the DRI drivers from loading but I still see the same > messages in the XF86 log file. Maybe I need to do something else to > stop > DRI from trying to load... > > thx, > > -dean andreakis > > On Fri, 2003-06-13 at 14:47, Alex Deucher wrote: > > this is from the DRI (front, back, and depth buffers) not the 2D > driver > > I think. > > > > Alex > > > > --- "Andreakis, Dean (MED)" <[EMAIL PROTECTED]> wrote: > > > > > > (WW) RADEON (0): Static buffer allocation failed -- need at least > > > 9216 > > > kB video memory > > > (II) RADEON (0): Memory manager initialzed to (0,0) (10124,2048) > > > (II) RADEON (0): Reserved area from (0,768) to (1024, 770) > > > (II) RADEON (0): Largest offscreen area available: 1024 x 1278 > > > > > > ... > > > > > > (WW) RADEON (1): Static buffer allocation failed -- need at least > > > 9216 > > > kB video memory > > > (II) RADEON (1): Memory manager initialzed to (0,0) (10124,2048) > > > (II) RADEON (1): Reserved area from (0,768) to (1024, 770) > > > (II) RADEON (1): Largest offscreen area available: 1024 x 1278 > > > > > > It seems confusing to me since I have 16MBytes of video memory > > > installed. For 1024x768x32bpp mode (worste case) this only > calculates > > > to > > > 3145728 bytes per screen but yet its telling me I need 9216 > kBytes > > > per > > > screen...h...must be more buffer allocation needed by the > chip > > > then > > > just the on-screen area frame buffer > > > > > > any thoughts? > > > > > > thx... > > > > > > -dean andreakis > > > > > > __ > > Do you Yahoo!? > > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > > http://calendar.yahoo.com > > ___ > > Devel mailing list > > [EMAIL PROTECTED] > > http://XFree86.Org/mailman/listinfo/devel > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Getting Dual Independent Heads to work on Debian(sid) on iBook
Alex, I went ahead and commented out the dri section and the Load "dri", Load "GLcore" and Load "glx" lines in the "Module" section of XF86Config-4 to try and prevent the DRI drivers from loading but I still see the same messages in the XF86 log file. Maybe I need to do something else to stop DRI from trying to load... thx, -dean andreakis On Fri, 2003-06-13 at 14:47, Alex Deucher wrote: > this is from the DRI (front, back, and depth buffers) not the 2D driver > I think. > > Alex > > --- "Andreakis, Dean (MED)" <[EMAIL PROTECTED]> wrote: > > > > (WW) RADEON (0): Static buffer allocation failed -- need at least > > 9216 > > kB video memory > > (II) RADEON (0): Memory manager initialzed to (0,0) (10124,2048) > > (II) RADEON (0): Reserved area from (0,768) to (1024, 770) > > (II) RADEON (0): Largest offscreen area available: 1024 x 1278 > > > > ... > > > > (WW) RADEON (1): Static buffer allocation failed -- need at least > > 9216 > > kB video memory > > (II) RADEON (1): Memory manager initialzed to (0,0) (10124,2048) > > (II) RADEON (1): Reserved area from (0,768) to (1024, 770) > > (II) RADEON (1): Largest offscreen area available: 1024 x 1278 > > > > It seems confusing to me since I have 16MBytes of video memory > > installed. For 1024x768x32bpp mode (worste case) this only calculates > > to > > 3145728 bytes per screen but yet its telling me I need 9216 kBytes > > per > > screen...h...must be more buffer allocation needed by the chip > > then > > just the on-screen area frame buffer > > > > any thoughts? > > > > thx... > > > > -dean andreakis > > > __ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.yahoo.com > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Getting Dual Independent Heads to work on Debian(sid) on iBook
this is from the DRI (front, back, and depth buffers) not the 2D driver I think. Alex --- "Andreakis, Dean (MED)" <[EMAIL PROTECTED]> wrote: > > (WW) RADEON (0): Static buffer allocation failed -- need at least > 9216 > kB video memory > (II) RADEON (0): Memory manager initialzed to (0,0) (10124,2048) > (II) RADEON (0): Reserved area from (0,768) to (1024, 770) > (II) RADEON (0): Largest offscreen area available: 1024 x 1278 > > ... > > (WW) RADEON (1): Static buffer allocation failed -- need at least > 9216 > kB video memory > (II) RADEON (1): Memory manager initialzed to (0,0) (10124,2048) > (II) RADEON (1): Reserved area from (0,768) to (1024, 770) > (II) RADEON (1): Largest offscreen area available: 1024 x 1278 > > It seems confusing to me since I have 16MBytes of video memory > installed. For 1024x768x32bpp mode (worste case) this only calculates > to > 3145728 bytes per screen but yet its telling me I need 9216 kBytes > per > screen...h...must be more buffer allocation needed by the chip > then > just the on-screen area frame buffer > > any thoughts? > > thx... > > -dean andreakis __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Getting Dual Independent Heads to work on Debian(sid) on iBook
Ben,
Thanks again. I see the section in radeonfb.c you mentioned below:
You are probably hitting this:
>
> if ((var->xoffset + var->xres > var->xres_virtual)
> || (var->yoffset + var->yres > var->yres_virtual))
>return -EINVAL;
>
> In radeonfb fb_pan_display()
Just as a quick test I commented this check out and now I don't see the
error ((EE) RADEON (0): FBIOPAN_DISPLAY: Invalid argument) in my XF86
log but I am still in clone mode. I also see the following in the XF86
log:
(WW) RADEON (0): Static buffer allocation failed -- need at least 9216
kB video memory
(II) RADEON (0): Memory manager initialzed to (0,0) (10124,2048)
(II) RADEON (0): Reserved area from (0,768) to (1024, 770)
(II) RADEON (0): Largest offscreen area available: 1024 x 1278
...
(WW) RADEON (1): Static buffer allocation failed -- need at least 9216
kB video memory
(II) RADEON (1): Memory manager initialzed to (0,0) (10124,2048)
(II) RADEON (1): Reserved area from (0,768) to (1024, 770)
(II) RADEON (1): Largest offscreen area available: 1024 x 1278
It seems confusing to me since I have 16MBytes of video memory
installed. For 1024x768x32bpp mode (worste case) this only calculates to
3145728 bytes per screen but yet its telling me I need 9216 kBytes per
screen...h...must be more buffer allocation needed by the chip then
just the on-screen area frame buffer
any thoughts?
thx...
-dean andreakis
On Fri, 2003-06-13 at 10:37, Benjamin Herrenschmidt wrote:
> On Fri, 2003-06-13 at 17:08, Andreakis, Dean (MED) wrote:
>
> > Given this result I tried comparing the sections of code in the kernel
> > fbdev driver and the XF86 radeon driver that sets up the PLL and there
> > was just a few minor diff's in the default min/max values. I went ahead
> > and changed these to match and recompiled/installed XFree86 4.3 etc. but
> > it didn't make any difference...the flickering still occured. Maybe I am
> > looking at the wrong parts of codehmmm
>
> Look for if (machine_is_compatible("PowerBook4,3")) in radeonfb, this
> is where I hard code the PLL value for the panel:
>
> if (machine_is_compatible("PowerBook4,3") && rinfo->arch == RADEON_M7)
> regs->ppll_div_3 = 0x000600ad;
>
> The yellow tint is usually a symptom of wrong endian. Look at the
> code that sets SURFACE_CNTL and tweak it (try setting bits for
> both apertures for example).
>
> > I guess the other weird thing is the color issue (yellowing). It also
> > seems to be related to the BusID setting. If I use 0:16:0 in the device
> > sections then its yellow. If I use 0:10:0 in just the external crt
> > device section (an incorrect value per your earlier comments) then the
> > colors are all ok on both screens etc...
>
> Hrm... Make no sense to me...
>
> > In any case I appreiciate your comments. I guess I really want to get
> > down to enabling the dual-head mode first and then I can worry about any
> > flickering and color issues secondarily. On that note I looked at my
> > XF86 log file and noticed the following error:
> >
> > (EE) RADEON (0): FBIOPAN_DISPLAY: Invalid argument
> >
> > This end up being in the fb_ioctl function in the kernel fbmem.c
> > module.I am not sure whats going on in this particular section so maybe
> > you can comment.
>
> You are probably hitting this:
>
> if ((var->xoffset + var->xres > var->xres_virtual)
> || (var->yoffset + var->yres > var->yres_virtual))
>return -EINVAL;
>
> In radeonfb fb_pan_display()
>
>
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Symbol unresolved problems..
It's in the libvbe.a module. We'll probably need to see the /var/log/XFree86.0.log to say more about why that's not resolved. It's usually because the driver didn't request that it be loaded, or if it crashes before then for some reason you often see messages about unresolved symbols when the server is aborting. Mark. On Thu, 12 Jun 2003, Jason Kim wrote: > Thank you ... > > No I didn't modify this symbol.. This symbol is "vbeFree". > > I didn't touch anything about Savage device driver, but savage_driver.o module can't > resolve the vbeFree symbol anymore... T.T > > jason > > - Original Message - > From: "Mark Vojkovich" <[EMAIL PROTECTED]> > To: "Jason Kim" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Thursday, June 12, 2003 9:34 PM > Subject: Re: Symbol unresolved problems.. > > > >Do you have a specific example? > > > >Are these symbols in your modifications? You can't call > > anything you like from within an XFree86 module. They don't, > > for instance, link against libc. There are only specific > > functions you can call - ones exported by the core server. > > > > Mark. > > > > On Thu, 12 Jun 2003, Jason Kim wrote: > > > > > Hi... > > > I modified xfree 4.3.? and successfuly compiled and installed it. When I start > > > X, I got some messages like "Symbol x in module x is not resolved". > > > > > > What is the main reason of these problems? What cause it? > > > > > > thank you.. > > > > > > > ___ > > Devel mailing list > > [EMAIL PROTECTED] > > http://XFree86.Org/mailman/listinfo/devel > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Getting Dual Independent Heads to work on Debian(sid) on iBook
On Fri, 2003-06-13 at 17:08, Andreakis, Dean (MED) wrote:
> Given this result I tried comparing the sections of code in the kernel
> fbdev driver and the XF86 radeon driver that sets up the PLL and there
> was just a few minor diff's in the default min/max values. I went ahead
> and changed these to match and recompiled/installed XFree86 4.3 etc. but
> it didn't make any difference...the flickering still occured. Maybe I am
> looking at the wrong parts of codehmmm
Look for if (machine_is_compatible("PowerBook4,3")) in radeonfb, this
is where I hard code the PLL value for the panel:
if (machine_is_compatible("PowerBook4,3") && rinfo->arch == RADEON_M7)
regs->ppll_div_3 = 0x000600ad;
The yellow tint is usually a symptom of wrong endian. Look at the
code that sets SURFACE_CNTL and tweak it (try setting bits for
both apertures for example).
> I guess the other weird thing is the color issue (yellowing). It also
> seems to be related to the BusID setting. If I use 0:16:0 in the device
> sections then its yellow. If I use 0:10:0 in just the external crt
> device section (an incorrect value per your earlier comments) then the
> colors are all ok on both screens etc...
Hrm... Make no sense to me...
> In any case I appreiciate your comments. I guess I really want to get
> down to enabling the dual-head mode first and then I can worry about any
> flickering and color issues secondarily. On that note I looked at my
> XF86 log file and noticed the following error:
>
> (EE) RADEON (0): FBIOPAN_DISPLAY: Invalid argument
>
> This end up being in the fb_ioctl function in the kernel fbmem.c
> module.I am not sure whats going on in this particular section so maybe
> you can comment.
You are probably hitting this:
if ((var->xoffset + var->xres > var->xres_virtual)
|| (var->yoffset + var->yres > var->yres_virtual))
return -EINVAL;
In radeonfb fb_pan_display()
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Getting Dual Independent Heads to work on Debian(sid) on iBook
Ben, Thanks for the information. I used fbset -x and updated XF86Config-4 accordingly. All of the test results from my original post were without using the kernel fbdev driver. I just now went ahead and added Option "UseFBDev" to the lcd-related device section in XF86Config-4 and set BusID to 0:16:0 in both device sections and now the lcd flickering is gone but both screens are yellow and I am still in clone mode.If I just comment out the Option "UseFBDev" then restart the X server then the lcd flickering returns (and both screens are still yellowish etc.). Given this result I tried comparing the sections of code in the kernel fbdev driver and the XF86 radeon driver that sets up the PLL and there was just a few minor diff's in the default min/max values. I went ahead and changed these to match and recompiled/installed XFree86 4.3 etc. but it didn't make any difference...the flickering still occured. Maybe I am looking at the wrong parts of codehmmm I guess the other weird thing is the color issue (yellowing). It also seems to be related to the BusID setting. If I use 0:16:0 in the device sections then its yellow. If I use 0:10:0 in just the external crt device section (an incorrect value per your earlier comments) then the colors are all ok on both screens etc... In any case I appreiciate your comments. I guess I really want to get down to enabling the dual-head mode first and then I can worry about any flickering and color issues secondarily. On that note I looked at my XF86 log file and noticed the following error: (EE) RADEON (0): FBIOPAN_DISPLAY: Invalid argument This end up being in the fb_ioctl function in the kernel fbmem.c module.I am not sure whats going on in this particular section so maybe you can comment. thanks again, -dean andreakis On Fri, 2003-06-13 at 09:06, Benjamin Herrenschmidt wrote: > > hing is ok. > > > > 2. On the iBook if I set both BusID's in both device sections to 0:10:0 > > then X won't startup even though this is the ID reported by lspci for > > the ATI chip. If I just set the BusID in the device section associated > > with the external CRT to 0:10:0 then X will start and the colors are ok > > but there are scrolling lines in the lcd panel. Also, if I run glxinfo > > then it reports information on just one screen even though I have > > defined two of them. > > I think lspci has hexadecimal output while XF86Config expects decimal, > try 0:16:0 > > > 3. If both are set to BusID 0:16:0 (or just the device section > > associated with the external CRT) then X starts but both screens are > > yellowish and there are scrolling lines in the lcd panel. Also, if I run > > glxinfo then it reports information on two screens (as I expect). > > First get the native modeline of your panel with fbset -x before you > launch X and make sure X uses that for the panel. > > Also, there is a problem with the LCD panel on some iBooks, possibly > yours. On these, for an unknown reason, the PLL values we calcule > provide a flickering display. I have hard coded values in radeonfb > but of course that's not a solution for you. Keeping the firmware set > values would work too if XFree driver can be instructed to do that. > > I'm not too sure how to solve that last problem properly. The > interesting fact is that if I use the same PLL values as MacOS uses, > I also have flickering display. So there is something else that is > interfering with the PLL in some way. It seems though that MacOS > reconfigure the MPLL and SPLL (to obtain the same final clocks but > using a different pair of dividers), there might be something related > to the flickering in there... Only ATI can tell. > > > >From previous mailing list responses around this issue and my test > > results so far I have thought that further development work is required > > on the radeon XFree86 4.3.0 drivers in order to properly enable this > > dual-headed mode on the iBook and relieve some of the other odd issues > > defined above. > > > > Any help in pointing me in the right direction as far as changes > > required etc. with the driver(s) would be appreciated. > > > > -dean andreakis > -- > Benjamin Herrenschmidt <[EMAIL PROTECTED]> > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Symbol unresolved problems..
Can you check if the vbe module is loaded (and not unloaded) at this point? Better yet, post your log file. Egbert. Alex Deucher writes: > I had this problem as well at one point when I was messing with the > savage driver. What was weird was I hadn't messed with any of the vbe > stuff. I think it ended up being a bad pointer reference or something > like that. also, if you are attempting to mess with programming > dualhead, you need to turn off the "usebios" mode stuff or it will muck > up the crtc's. > > Alex > > --- Jason Kim <[EMAIL PROTECTED]> wrote: > > Thank you ... > > > > No I didn't modify this symbol.. This symbol is "vbeFree". > > > > I didn't touch anything about Savage device driver, but > > savage_driver.o module can't resolve the vbeFree symbol anymore... > > T.T > > > > jason > > > > > __ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.yahoo.com > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Getting Dual Independent Heads to work on Debian(sid) on iBook
On Fri, 2003-06-13 at 00:10, Alex Deucher wrote: > there are alot of issues with dualhead and LCDs on PPC. I believe the > fix is to use fbdev, but I'm not sure anyone has gotten dualhead to > work yet. check the archives from last month. I had it working on the M6 a while ago, I haven't yet tried with the M9. I know Michel had it working with the M7 in a titanium powerbook, though there are known problems with that same chip when used in iBooks (see my other mail) Ben. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Getting Dual Independent Heads to work on Debian(sid) on iBook
> hing is ok. > > 2. On the iBook if I set both BusID's in both device sections to 0:10:0 > then X won't startup even though this is the ID reported by lspci for > the ATI chip. If I just set the BusID in the device section associated > with the external CRT to 0:10:0 then X will start and the colors are ok > but there are scrolling lines in the lcd panel. Also, if I run glxinfo > then it reports information on just one screen even though I have > defined two of them. I think lspci has hexadecimal output while XF86Config expects decimal, try 0:16:0 > 3. If both are set to BusID 0:16:0 (or just the device section > associated with the external CRT) then X starts but both screens are > yellowish and there are scrolling lines in the lcd panel. Also, if I run > glxinfo then it reports information on two screens (as I expect). First get the native modeline of your panel with fbset -x before you launch X and make sure X uses that for the panel. Also, there is a problem with the LCD panel on some iBooks, possibly yours. On these, for an unknown reason, the PLL values we calcule provide a flickering display. I have hard coded values in radeonfb but of course that's not a solution for you. Keeping the firmware set values would work too if XFree driver can be instructed to do that. I'm not too sure how to solve that last problem properly. The interesting fact is that if I use the same PLL values as MacOS uses, I also have flickering display. So there is something else that is interfering with the PLL in some way. It seems though that MacOS reconfigure the MPLL and SPLL (to obtain the same final clocks but using a different pair of dividers), there might be something related to the flickering in there... Only ATI can tell. > >From previous mailing list responses around this issue and my test > results so far I have thought that further development work is required > on the radeon XFree86 4.3.0 drivers in order to properly enable this > dual-headed mode on the iBook and relieve some of the other odd issues > defined above. > > Any help in pointing me in the right direction as far as changes > required etc. with the driver(s) would be appreciated. > > -dean andreakis -- Benjamin Herrenschmidt <[EMAIL PROTECTED]> ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Symbol unresolved problems..
I had this problem as well at one point when I was messing with the savage driver. What was weird was I hadn't messed with any of the vbe stuff. I think it ended up being a bad pointer reference or something like that. also, if you are attempting to mess with programming dualhead, you need to turn off the "usebios" mode stuff or it will muck up the crtc's. Alex --- Jason Kim <[EMAIL PROTECTED]> wrote: > Thank you ... > > No I didn't modify this symbol.. This symbol is "vbeFree". > > I didn't touch anything about Savage device driver, but > savage_driver.o module can't resolve the vbeFree symbol anymore... > T.T > > jason > __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
