Re: Does anyone know the mechanism in Nokia's LCD driver?
On Tuesday 13 January 2009, Frantisek Dufka wrote: Siarhei Siamashka wrote: XV should make a perfect backend for SDL, because it maps fine on SDL API (SDL_SetVideoMode/SDL_Flip/...). In general, XV is a good backend for anything that uses double-buffered or triple-buffered fullscreen/fullwindow blits. It is possible to get ~27.5 frames per second in 800x480 resolution for 16bpp rgb color format without tearing. With a lower resolution it is possible to go up to ~55 frames per second. Hmm, I hope there is some work done on this front (Xv or even openGLES based backend for SDL) for Fremantle. The alpha release has same old 1.2.8-23 SDL version though. Or is there some alternative to SDL for 2D graphics? I was only talking about N800/N810 hardware, its kernel, xserver, SDL and how to best use them on the current generation of internet tablets. Fremantle is a completely different subject and I don't feel like discussing it yet. It surely will bring new exciting features and challenges. Regarding improved SDL or whatever is needed for 2D games, in any case it is one of the things that the community can do with or without official Nokia support. BTW, as for the external lcd controller status - I have just checked and CONFIG_FB_OMAP_LCDC_EXTERNAL is disabled for both RX-51 confugurations in Fremantle alpha kernel (unlike e.g. PowerVR stuff) so maybe we finally has directly mapped framebuffer in SDRAM ? We can discuss this stuff after the actual HW is out :) -- Best regards, Siarhei Siamashka ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does anyone know the mechanism in Nokia's LCD driver?
Huang Gao (Gmail) wrote: Dear all Maemo fans: I just noticed that Maemo used a different mechanism in LCD driver from normal FB drivers. It seemed that Maemo does not use the automatic DMA refresh in the driver, which is replaced by an ioctl named OMAPFB_UPDATE_WINDOW, and a method called TEARSYNC. However, I am confused why it will improve the performance of graphics applications. Is there anyone that may give me some tips on this topic? This was done because of relatively high resolution (800x480x16 bits). Automatic DMA would continuously steal a lot of SDRAM cycles and slowed down everything. Perhaps it would also eat more power and prevented system from sleep when the display is on. I wonder if this is still the case for upcoming OMAP3 based device. BTW, there is kernel ioctl to set automatic refresh and the refresh rate can be tweaked in kernel source but the results are suboptimal. Maybe at least for Nokia 770 it would be possible to use tearsync flag for such automatic update and set the update timer to lcd refresh rate or lcd refresh rate/2 to get nice result. N8x0 cannot update whole screen in one lcd refresh cycle anyway so you'll always get tearing on the bottom. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Does anyone know the mechanism in Nokia's LCD driver?
Hi, Frantisek: Thank you for your reply! But I am still wondering why the screen will not flicker if the DMA only refreshes when the data changed. Does Nokia uses something like smart panel? Best Regards Huang Gao(黄杲) -邮件原件- 发件人: Frantisek Dufka [mailto:duf...@seznam.cz] 发送时间: 2009年1月13日 16:56 收件人: Huang Gao (Gmail) 抄送: maemo-developers@maemo.org 主题: Re: Does anyone know the mechanism in Nokia's LCD driver? Huang Gao (Gmail) wrote: Dear all Maemo fans: I just noticed that Maemo used a different mechanism in LCD driver from normal FB drivers. It seemed that Maemo does not use the automatic DMA refresh in the driver, which is replaced by an ioctl named OMAPFB_UPDATE_WINDOW, and a method called TEARSYNC. However, I am confused why it will improve the performance of graphics applications. Is there anyone that may give me some tips on this topic? This was done because of relatively high resolution (800x480x16 bits). Automatic DMA would continuously steal a lot of SDRAM cycles and slowed down everything. Perhaps it would also eat more power and prevented system from sleep when the display is on. I wonder if this is still the case for upcoming OMAP3 based device. BTW, there is kernel ioctl to set automatic refresh and the refresh rate can be tweaked in kernel source but the results are suboptimal. Maybe at least for Nokia 770 it would be possible to use tearsync flag for such automatic update and set the update timer to lcd refresh rate or lcd refresh rate/2 to get nice result. N8x0 cannot update whole screen in one lcd refresh cycle anyway so you'll always get tearing on the bottom. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Does anyone know the mechanism in Nokia's LCD driver?
Hi, On Tue, 2009-01-13 at 17:21 +0800, ext Huang Gao (Gmail) wrote: But I am still wondering why the screen will not flicker if the DMA only refreshes when the data changed. Does Nokia uses something like smart panel? There is an external HW framebuffer between omap and the lcd -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does anyone know the mechanism in Nokia's LCD driver?
On Tue, Jan 13, 2009 at 10:56 AM, Frantisek Dufka duf...@seznam.cz wrote: BTW, there is kernel ioctl to set automatic refresh and the refresh rate can be tweaked in kernel source but the results are suboptimal. Maybe at least for Nokia 770 it would be possible to use tearsync flag for such automatic update and set the update timer to lcd refresh rate or lcd refresh rate/2 to get nice result. N8x0 cannot update whole screen in one lcd refresh cycle anyway so you'll always get tearing on the bottom. N8x0 can update whole screen in two lcd refresh cycles (but admittedly it just barely crosses this limit), which is enough to have no tearing. But this is only true when running at OP 0 (400MHz). When running at other operating points, RFBI is slower. It may be interesting to experiment with better integration of omapfb kernel driver with DVFS and try to always switch (at least temporarily) to OP 0 when performing screen updates. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Does anyone know the mechanism in Nokia's LCD driver?
Hi, On Tue, 2009-01-13 at 18:06 +0800, ext Huang Gao (Gmail) wrote: Hi, Igor Stoppa: Thank you for your reply! So can I understand that this hardware FB is not contained in SDRAM or SRAM, and LCD will refresh itself from this hardware FB by its controller automatically, without the help of OMAP DMA channel? I'm in no way a display guy but iirc there are 2 modes for refresh: -auto: whatever is written to the framebuffer goes through straight to the LCD -manual: the image needs to be flushed to the LCD If you are interested, you can check it from the kernel source files. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does anyone know the mechanism in Nokia's LCD driver?
On Tue, 2009-01-13 at 12:23 +0200, ext Felipe Contreras wrote: On Tue, Jan 13, 2009 at 12:05 PM, Igor Stoppa igor.sto...@nokia.com wrote: Hi, On Tue, 2009-01-13 at 18:06 +0800, ext Huang Gao (Gmail) wrote: Hi, Igor Stoppa: Thank you for your reply! So can I understand that this hardware FB is not contained in SDRAM or SRAM, and LCD will refresh itself from this hardware FB by its controller automatically, without the help of OMAP DMA channel? I'm in no way a display guy but iirc there are 2 modes for refresh: -auto: whatever is written to the framebuffer goes through straight to the LCD -manual: the image needs to be flushed to the LCD If you are interested, you can check it from the kernel source files. Would the manual mode help to avoid tearing? but afaik it is already used by default -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Does anyone know the mechanism in Nokia's LCD driver?
Hi, Igor Stoppa: Thank you for your reply! So can I understand that this hardware FB is not contained in SDRAM or SRAM, and LCD will refresh itself from this hardware FB by its controller automatically, without the help of OMAP DMA channel? Best Regards Huang Gao(黄杲) -邮件原件- 发件人: Igor Stoppa [mailto:igor.sto...@nokia.com] 发送时间: 2009年1月13日 17:21 收件人: ext Huang Gao (Gmail) 抄送: 'Frantisek Dufka'; maemo-developers@maemo.org 主题: RE: Does anyone know the mechanism in Nokia's LCD driver? Hi, On Tue, 2009-01-13 at 17:21 +0800, ext Huang Gao (Gmail) wrote: But I am still wondering why the screen will not flicker if the DMA only refreshes when the data changed. Does Nokia uses something like smart panel? There is an external HW framebuffer between omap and the lcd -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does anyone know the mechanism in Nokia's LCD driver?
On Tue, Jan 13, 2009 at 12:05 PM, Igor Stoppa igor.sto...@nokia.com wrote: Hi, On Tue, 2009-01-13 at 18:06 +0800, ext Huang Gao (Gmail) wrote: Hi, Igor Stoppa: Thank you for your reply! So can I understand that this hardware FB is not contained in SDRAM or SRAM, and LCD will refresh itself from this hardware FB by its controller automatically, without the help of OMAP DMA channel? I'm in no way a display guy but iirc there are 2 modes for refresh: -auto: whatever is written to the framebuffer goes through straight to the LCD -manual: the image needs to be flushed to the LCD If you are interested, you can check it from the kernel source files. Would the manual mode help to avoid tearing? -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does anyone know the mechanism in Nokia's LCD driver?
On Tue, Jan 13, 2009 at 12:23 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Jan 13, 2009 at 12:05 PM, Igor Stoppa igor.sto...@nokia.com wrote: Hi, On Tue, 2009-01-13 at 18:06 +0800, ext Huang Gao (Gmail) wrote: Hi, Igor Stoppa: Thank you for your reply! So can I understand that this hardware FB is not contained in SDRAM or SRAM, and LCD will refresh itself from this hardware FB by its controller automatically, without the help of OMAP DMA channel? I'm in no way a display guy but iirc there are 2 modes for refresh: -auto: whatever is written to the framebuffer goes through straight to the LCD -manual: the image needs to be flushed to the LCD If you are interested, you can check it from the kernel source files. Would the manual mode help to avoid tearing? Yes, and it does help to avoid tearing. At least this works fine for XV extension. But getting tearfree scrolling/panning in GTK applications for example is a bit more challenging. I can provide a more detailed explanation if anybody is interested. XV should make a perfect backend for SDL, because it maps fine on SDL API (SDL_SetVideoMode/SDL_Flip/...). In general, XV is a good backend for anything that uses double-buffered or triple-buffered fullscreen/fullwindow blits. It is possible to get ~27.5 frames per second in 800x480 resolution for 16bpp rgb color format without tearing. With a lower resolution it is possible to go up to ~55 frames per second. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Does anyone know the mechanism in Nokia's LCD driver?
Hi, Frantisek: I now understand. Thank you for your explanation! Best Regards Huang Gao(黄杲) -邮件原件- 发件人: Frantisek Dufka [mailto:duf...@seznam.cz] 发送时间: 2009年1月13日 18:49 收件人: ext Huang Gao (Gmail) 抄送: igor.sto...@nokia.com; maemo-developers@maemo.org 主题: Re: Does anyone know the mechanism in Nokia's LCD driver? Igor Stoppa wrote: Hi, On Tue, 2009-01-13 at 18:06 +0800, ext Huang Gao (Gmail) wrote: So can I understand that this hardware FB is not contained in SDRAM or SRAM, and LCD will refresh itself from this hardware FB by its controller automatically, without the help of OMAP DMA channel? Yes. The Epson S1D13742 (770) or S1D13745 (N8x0) lcd controller has its own video RAM. I'm in no way a display guy but iirc there are 2 modes for refresh: -auto: whatever is written to the framebuffer goes through straight to the LCD -manual: the image needs to be flushed to the LCD Well, both modes use same way for transferring data to LCD, the only difference is when the update is done. Either periodically from timer or when update ioctl is called. The source is here http://mxr.maemo.org/diablo/source/kernel-source-diablo-2.6.21/kernel-source /drivers/video/omap/ see omapfb_main, rfbi (n8x0) or sossi (770), blizzard (N8x0) or hwa742 (770), lcd_mipid. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Does anyone know the mechanism in Nokia's LCD driver?
Would the manual mode help to avoid tearing? Yes, and it does help to avoid tearing. At least this works fine for XV extension. But getting tearfree scrolling/panning in GTK applications for example is a bit more challenging. I can provide a more detailed explanation if anybody is interested. Yes please :) Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does anyone know the mechanism in Nokia's LCD driver?
Siarhei Siamashka wrote: XV should make a perfect backend for SDL, because it maps fine on SDL API (SDL_SetVideoMode/SDL_Flip/...). In general, XV is a good backend for anything that uses double-buffered or triple-buffered fullscreen/fullwindow blits. It is possible to get ~27.5 frames per second in 800x480 resolution for 16bpp rgb color format without tearing. With a lower resolution it is possible to go up to ~55 frames per second. Hmm, I hope there is some work done on this front (Xv or even openGLES based backend for SDL) for Fremantle. The alpha release has same old 1.2.8-23 SDL version though. Or is there some alternative to SDL for 2D graphics? BTW, as for the external lcd controller status - I have just checked and CONFIG_FB_OMAP_LCDC_EXTERNAL is disabled for both RX-51 confugurations in Fremantle alpha kernel (unlike e.g. PowerVR stuff) so maybe we finally has directly mapped framebuffer in SDRAM ? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Does anyone know the mechanism in Nokia's LCD driver?
Dear all Maemo fans: I just noticed that Maemo used a different mechanism in LCD driver from normal FB drivers. It seemed that Maemo does not use the automatic DMA refresh in the driver, which is replaced by an ioctl named OMAPFB_UPDATE_WINDOW, and a method called TEARSYNC. However, I am confused why it will improve the performance of graphics applications. Is there anyone that may give me some tips on this topic? Thanks in advance! Best Regards Huang Gao(黄杲) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
