[Bug 36812] GPU lockup in Team Fortress 2
https://bugs.freedesktop.org/show_bug.cgi?id=36812 --- Comment #4 from Tom Stellard 2011-05-17 21:21:18 PDT --- If you run with MESA_GLSL=nopt, does it still crash? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] Standardize YUV support in the fbdev API
Oops. Nevermind, you already have looked at what ivtvfb does. -Andy
[RFC] drm: add overlays as first class KMS objects
Hi Daniel, On Friday 13 May 2011 18:16:30 Daniel Vetter wrote: > Hi Jesse, > > Discussion here in Budapest with v4l and embedded graphics folks was > extremely fruitful. A few quick things to take away - I'll try to dig > through all > the stuff I've learned more in-depth later (probably in a blog post or > two): > > - embedded graphics is insane. The output routing/blending/whatever > currently shipping hw can do is crazy and kms as-is is nowhere near up > to snuff to support this. We've discussed omap4 and a ti chip targeted at > video surveillance as use cases. I'll post block diagrams and > explanations some when later. > - we should immediately stop to call anything an overlay. It's a confusing > concept that has a different meaning in every subsystem and for every hw > manufacturer. More sensible names are dma fifo engines for things that > slurp in planes and make them available to the display subsystem. Blend > engines for blocks that take multiple input pipes and overlay/underlay/blend > them together. Display subsytem/controller for the aggregate thing including > encoders/resizers/outputs and especially the crazy routing network that > connects everything. > > Most of the discussion centered around clearing up the confusion and > reaching a mutual understanding between desktop graphics, embedded > graphics and v4l people. Two rough ideas emerged though: > > 1) Splitting the crtc object into two objects: crtc with associated output > mode (pixel clock, encoders/connectors) and dma engines (possibly > multiple) that feed it. omap 4 has essentially just 4 dma engines that can > be freely assigned to the available outputs, so a distinction between > normal crtcs and overlay engines just does not make sense. There's the > major open question of where to put the various attributes to set up the > output pipeline. Also some of these attributes might need to be changed > atomicly together with pageflips on a bunch of dma engines all associated > with the same crtc on the next vsync, e.g. output position of an overlaid > video buffer. I like that idea. Setting attributes atomically will likely be one of the biggest challenge. V4L2 shares the same need, but we haven't had time to address it yet. > 2) The above should be good enough to support halfway sane chips like > omap4. But hw with more insane routing capabilities that can also use v4l > devices as sources (even video input connectors) media controller might be > a good fit. Media controller is designed to expose multimedia pipe routing > across different subsystem. But the first version, still marked > experimental, only got merged in .39. We discussed a few ideas as how to > splice media controller into kms but nothing clear emerged. So a possible > kms integration with media controller is rather far away. You're probably right, but far away doesn't mean never. Especially when one of the media controller developers is interested in the project and could spend time on it :-) I've started working on a prototype implementation that would use the media controller API to report the CRTCs, encoders and connectors topology to userspace. The learning curve is pretty steep as I'm not familiar with the DRM and KMS code, but the code base turned out to be much easier to dive in than it seemed a couple of years ago. -- Regards, Laurent Pinchart
[RFC] Standardize YUV support in the fbdev API
On Wed, 2011-05-18 at 00:07 +0200, Laurent Pinchart wrote:
> Hi everybody,
>
> I need to implement support for a YUV frame buffer in an fbdev driver. As the
> fbdev API doesn't support this out of the box, I've spent a couple of days
> reading fbdev (and KMS) code and thinking about how we could cleanly add YUV
> support to the API. I'd like to share my findings and thoughts, and hopefully
> receive some comments back.
I haven't looked at anything below, but I'll mention that the ivtv
driver presents an fbdev interface for the YUV output stream of the
CX23415.
It may be worth a look and asking Hans what are the short-comings.
-Andy
> The terms 'format', 'pixel format', 'frame buffer format' and 'data format'
> will be used interchangeably in this e-mail. They all refer to the way pixels
> are stored in memory, including both the representation of a pixel as integer
> values and the layout of those integer values in memory.
>
>
> History and current situation
> -
>
> The fbdev API predates YUV frame buffers. In those old days developers only
> cared (and probably thought) about RGB frame buffers, and they developed an
> API that could express all kind of weird RGB layout in memory (such as R-
> GGG- for instance, I can't imagine hardware implementing that).
> This resulted in individual bit field description for the red, green, blue
> and
> alpha components:
>
> struct fb_bitfield {
> __u32 offset; /* beginning of bitfield*/
> __u32 length; /* length of bitfield */
> __u32 msb_right; /* != 0 : Most significant bit is */
>/* right */
> };
>
> Grayscale formats were pretty common, so a grayscale field tells color
> formats
> (grayscale == 0) from grayscale formats (grayscale != 0).
>
> People already realized that hardware developers were crazily inventive (the
> word to remember here is crazily), and that non-standard formats would be
> needed at some point. The fb_var_screeninfo ended up containing the following
> format-related fields.
>
> struct fb_var_screeninfo {
> ...
> __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 */
> ...
> };
>
> Two bits have been specified for the nonstd field:
>
> #define FB_NONSTD_HAM 1 /* Hold-And-Modify (HAM)*/
> #define FB_NONSTD_REV_PIX_IN_B 2 /* order of pixels in each byte is
> reversed
> */
>
> The FB_NONSTD_HAM bit is used by the video/amifb.c driver only to enable HAM
> mode[1]. I very much doubt that any new hardware will implement HAM mode (and
> I certainly hope none will).
>
> The FB_NONSTD_REV_PIX_IN_B is used in video/fb_draw.h by the generic bitblit,
> fillrect and copy area implementations, not directly by drivers.
>
> A couple of drivers hardcode the nonstd field to 1 for some reason. Those are
> video/arcfb.c (1bpp gray display), video/hecubafb.c (1bpp gray display) and
> video/metronomefb.c (8bpp gray display).
>
> The following drivers use nonstd for various other (and sometimes weird)
> purposes:
>
> video/arkfb.c
> Used in 4bpp mode only, to control fb_setcolreg operation
> video/fsl-diu-fb.c
> Set var->nonstd bits into var->sync (why?)
> video/pxafb.c
> Encode frame buffer xpos and ypos in the nonstd field
> video/s3fb.c
> Used in 4bpp mode only, to control fb_setcolreg operation
> video/vga16fb.c
> When panning in non-8bpp, non-text mode, decrement xoffset
> Do some other weird stuff when not 0
> video/i810/i810_main.c
> Select direct color mode when set to 1 (truecolor otherwise)
>
> Fast forward a couple of years, hardware provides support for YUV frame
> buffers. Several drivers had to provide YUV format selection to applications,
> without any standard API to do so. All of them used the nonstd field for that
> purpose:
>
> media/video/ivtv/
> Enable YUV mode when set to 1
> video/pxafb.c
> Encode pixel format in the nonstd field
> video/sh_mobile_lcdfb.c
> If bpp == 12 and nonstd != 0, enable NV12 mode
> If bpp == 16 or bpp == 24, ?
> video/omap/omapfb_main.c
> Select direct color mode when set to 1 (depend on bpp otherwise)
> Used as a pixel format identifier (YUV422, YUV420 or YUY422)
> video/omap2/omapfb/omapfb-main.c
> Select direct color mode when set to 1 (depend on bpp otherwise)
> Used as a pixel format identifier
[Bug 36753] Some textures now rendered as completely black after register allocator rewrite.
https://bugs.freedesktop.org/show_bug.cgi?id=36753 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Tom Stellard 2011-05-17 19:18:57 PDT --- Fixed in git by commit 217cd216eac65983004ca77a9e49dbfad1b720b6. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36172] xf86-video-ati-git causes Gnome 3 crash (Radeon HD5770 - r800)
https://bugs.freedesktop.org/show_bug.cgi?id=36172 Jonathan Serafini changed: What|Removed |Added CC||serafini at archlinux.us --- Comment #9 from Jonathan Serafini 2011-05-17 18:28:10 PDT --- Hi Michel, Good first troubleshooting steps. I too experienced the exact same errors (radeonSetSpanFunctions: bad format:) as soon as I would touch any of the widgets on the panel (ex.: volume control). I too run archlinux and was running most of the same -git ati/dri/mesa stack as Sascha. Apparently, downgrading libdrm-git-20110512-1-x86_64.pkg.tar.xz to libdrm-2.4.25-1-x86_64.pkg.tar.xz seems to have done the trick. Should you need more info, please let me know. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
i915/kms/backlight-combo mode problem
Melchior,
I want to double check with you. If you change brightness from lowest
to highest, the LPBC value changes this way
Highest Lowest
0x10 , 0x19 .. 0xe5
And vice versa, from Lowest to Highest
Lowest Highest
0xe5 , .. 0x19 0x10
If above is true, then you have a very particular notebook that
reverse the sense of the LPBC values I don't know who ever came
across such device. wow.
Regarding that your brightness control key, due to that it is
controlled by acer_wmi and likely that BIOS aware this, it would do
brightness in a reversed way. I think Joey would check DSDT and see
any clue or evidence for this. OTOH the i915 driver didn't aware of
this and operates as usual sense that means falling into the trap.
PS. I see your log always reverse the sense of this LPBC value, now I
know why. :)
Regards,
Michael Chang
2011/5/17 Melchior FRANZ :
> * Michael Chang -- Tuesday 17 May 2011:
> [LBPC]
>> You can know your LPBC value by:
>> ? $ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}'
>>
>> And alter it's value via setpci (assuming set it to max)
>> ? $ setpci -s 00:02.0 F4.B=ff
>>
>> I assume you've tried this .. as you report setpci works for you. :)
>
> Ahh, yes, indeed. This lspci line (almost) always shows a value that
> corresponds with the actual backlight brightness, and both lines work
> with and without acpi_osi=Linux. (Whereas adjustment via keys only works
> *with* acpi_osi=Linux.) ?(Tested with 2.6.39-rc7/bd1a643e10)
>
>
>
>> Could you help to get the LPBC value in the initial dark condition? If
>> it's not corresponds to 255, maybe something sneaks and changes it but
>> not logged.
>
> Initially (with acpi_osi=Linux) LPBC=0xff. After "brightness down"
> it's 0x19, and after then pressing "brightness up" it's 0x01. The lowest
> value I can achieve after pressing "brightness down" a few times is 0xe5,
> the highest is 0x01. Neither 0xff nor 0x00 can be reached via keys, but
> can (most of the time -- see below!) be set with the setpci line and give
> the expected results, backlight off and fully on. ("display toggle" has
> no effect on LBPC, btw.)
>
> Setting 0xFF doesn't always turn the backlight off, though! If LBPC is
> at the (key) maximum 0x01, then setting 0xFF via setpci changes only the
> LBPC value as shown by lspci, but the backlight isn't actually turned off!
> If I then press "backlight darker" once (LBPC=0x19), then setting 0xFF
> via setpci works again.
>
>
>
>> ?1. $ dmesg -c
>> ?2. Close the lid
>> ?3. Open the lid
>> ?4. $ dmesg > dmesg.lid
>
> The results are:
>
> [ ?188.571040] [drm:intel_panel_set_backlight], set backlight PWM = 736950
> [ ?188.571048] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE =
> 1073741824
> [ ?188.571054] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE =
> 1073741824
> [ ?188.571059] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
> [ ?188.571064] [drm:intel_panel_set_backlight], set backlight max = 736950
> [ ?188.571069] [drm:intel_panel_set_backlight], set backlight lbpc = 255
> [ ?188.571075] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189399040
> [ ?188.571080] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [ ?188.571084] [drm:intel_panel_set_backlight],
> [ ?188.571088] [drm:intel_opregion_asle_intr], non asle set request??
> [ ?188.571093] set backlight level = 2890
>
> The backlight is off now, as always after closing/reopening the lid,
> and LPBC=0xff.
>
> m.
>
>
>
> PS: I'd be willing to join an irc.freenode.net channel in case you or
> ? ?anyone else wants quicker ("live") responses to such queries.
>
[PULL] drm-intel-next
On Tue, 17 May 2011 15:00:01 -0700, Keith Packard wrote: > > I've pushed four more patches to this branch for your merging pleasure. And, one more which fixes non-eDP displays on Ironlake systems after the Ivybridge merge. Sorry for not catching that in our testing... The following changes since commit a51f7a66fb5e4af5ec4286baef940d06594b59d2: drm/i915: enable rc6 by default (2011-05-17 14:33:38 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git drm-intel-next Keith Packard (1): drm/i915: FDI link training broken on Ironlake by Ivybridge integration drivers/gpu/drm/i915/intel_display.c |8 1 files changed, 4 insertions(+), 4 deletions(-) -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110517/fffe2832/attachment-0001.pgp>
i915/kms/backlight-combo mode problem
2011/5/16 Melchior FRANZ :
> I don't even know what an LBPC is, other than a variable named like that.
> So I'd need a hint for how to test that.
It resides at your vga adapter's pci configuration space, offset 0xf4.
You can know your LPBC value by:
$ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}'
And alter it's value via setpci (assuming set it to max)
$ setpci -s 00:02.0 F4.B=ff
I assume you've tried this .. as you report setpci works for you. :)
[PULL] drm-intel-next
I've pushed four more patches to this branch for your merging pleasure. > * Disabling FBC on Ironlake to enable RC6 instead Two patches for this are included. The following changes since commit 645c62a5e95a5f9a8e0d0627446bbda4ee042024: drm/i915: split PCH clock gating init (2011-05-13 18:12:53 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git drm-intel-next Feng, Boqun (2): drm/i915: fix user irq miss in BSD ring on g4x drm/i915: clean up unused ring_get_irq/ring_put_irq functions Jesse Barnes (2): drm/i915: add fbc enable flag, but disable by default drm/i915: enable rc6 by default drivers/gpu/drm/i915/i915_debugfs.c |3 ++ drivers/gpu/drm/i915/i915_drv.c |7 +++- drivers/gpu/drm/i915/i915_drv.h |2 + drivers/gpu/drm/i915/intel_display.c|5 +++ drivers/gpu/drm/i915/intel_ringbuffer.c | 50 ++ 5 files changed, 38 insertions(+), 29 deletions(-) -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110517/c5b7fa2e/attachment.pgp>
PROBLEM: i915 regression between 2.6.39-rc6 and 2.6.39-rc7
Hello, When running the 2.6.39-rc7, I've observed a problem on my laptop (DELL XPS15) which uses the i915 driver. Frequently, when moving the mouse over, the cursor does only trigger the modification on the desktop after a few seconds (like icons highligthing). When this occurs, the following message appear in the kernel log at the moment when the waited action occurs: [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 905, at 905], missed IRQ? Switching back to 2.6.39-rc6 fixes the issue. It runs gnome 3 which uses glx to add some effect. Maybe this is linked. When using the simple twm window manager, the problem does not seem to occur. Keywords: drm, i915 Kernel version: Linux version 2.6.39-rc7+ (eric at tiger) (gcc version 4.6.1 20110507 (prerelease) (Debian 4.6.0-7) ) #3 SMP Sun May 15 11:31:14 CEST 2011 Processor: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz Kernel log for i915: May 17 13:30:36 tiger kernel: [ 15.458754] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 May 17 13:30:36 tiger kernel: [ 15.458760] i915 :00:02.0: setting latency timer to 64 May 17 13:30:36 tiger kernel: [ 15.513847] i915 :00:02.0: irq 52 for MSI/MSI-X May 17 13:30:36 tiger kernel: [ 16.011208] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 May 17 13:31:12 tiger kernel: [ 59.343937] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 905, at 905], missed IRQ? May 17 13:31:17 tiger kernel: [ 63.998439] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 947, at 947], missed IRQ? May 17 13:32:27 tiger kernel: [ 134.591975] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 49015, at 49015], missed IRQ? May 17 13:32:29 tiger kernel: [ 136.127493] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 49154, at 49154], missed IRQ? lspci - for i915: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Device 04b6 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0300c Data: 41c9 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 lspci: 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation 2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 6 Series Chipset Family High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 1 (rev b5) 00:1c.1 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 2 (rev b5) 00:1c.3 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 4 (rev b5) 00:1c.4 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 5 (rev b5) 00:1c.5 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 6 (rev b5) 00:1d.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation HM67 Express Chipset Family LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 6 Series Chipset Family 6 port SATA AHCI Controller (rev 05) 00:1f.3 SMBus: Intel Corporation 6 Series Chipset Family SMBus Controller (rev 05) 01:00.0 VGA compatible controller: nVidia Corporation Device 0df5 (rev a1) 03:00.0 Network controller: Intel Corporation Centrino Wireless-N 1000 04:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) ver_linux output: Linux tiger 2.6.39-rc7+ #3 SMP Sun May 15 11:31:14 CEST 2011 x86_64 GNU/Linux Gnu C 4.6.1 Gnu make 3.81 binutils
Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 16-05-2011 17:45, Guennadi Liakhovetski escreveu: > On Sat, 14 May 2011, Mauro Carvalho Chehab wrote: > >> Em 18-04-2011 17:15, Jesse Barker escreveu: >>> One of the big issues we've been faced with at Linaro is around GPU >>> and multimedia device integration, in particular the memory management >>> requirements for supporting them on ARM. This next cycle, we'll be >>> focusing on driving consensus around a unified memory management >>> solution for embedded systems that support multiple architectures and >>> SoCs. This is listed as part of our working set of requirements for >>> the next six-month cycle (in spite of the URL, this is not being >>> treated as a graphics-specific topic - we also have participation from >>> multimedia and kernel working group folks): >>> >>> https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics >> >> As part of the memory management needs, Linaro organized several discussions >> during Linaro Development Summit (LDS), at Budapest, and invited me and other >> members of the V4L and DRI community to discuss about the requirements. >> I wish to thank Linaro for its initiative. > > [snip] > >> Btw, the need of managing buffers is currently being covered by the proposal >> for new ioctl()s to support multi-sized video-buffers [1]. >> >> [1] http://www.spinics.net/lists/linux-media/msg30869.html >> >> It makes sense to me to discuss such proposal together with the above >> discussions, >> in order to keep the API consistent. > > The author of that RFC would have been thankful, if he had been put on > Cc: ;) If I had added everybody interested on this summary, probably most smtp servers would refuse to deliver the message thinking that it is a SPAM ;) My intention were to submit a feedback about it when analysing your rfc patches, if you weren't able to see it before. > But anyway, yes, consistency is good, but is my understanding > correct, that functionally these two extensions - multi-size and > buffer-forwarding/reuse are independent? Yes. > We have to think about making the > APIs consistent, e.g., by reusing data structures. But it's also good to > make incremental smaller changes where possible, isn't it? So, yes, we > should think about consistency, but develop and apply those two extensions > separately? True, but one discussion can benefit the other. IMO, we should not rush new userspace API merges, to avoid merging a code that weren't reasonably discussed, as otherwise, the API will become too messy. Thanks, Mauro.
i915/kms/backlight-combo mode problem
Hey,
* Michael Chang -- Tuesday 17 May 2011:
> If you change brightness from lowest to highest, the LPBC value changes
> this way
>
> Highest Lowest
> 0x10 , 0x19 .. 0xe5
Yes. (Though it's 0x01, not 0x10.)
---0xFF ... initial value and after closing/reopening lid
| 0xE5 \ ... dark
| 0xCC |
| 0xB2 |
(1)| 0x99 |
| 0x7F |_key adjustable range
| 0x66 |
| 0x4C |
| 0x33 |
-->0x19 |
0x01 / ... bright
0x00 ... also bright, only settable with setpci
(1) is the jump that resurrects the backlight from darkness by
pressing the "brightness down" key
And again, if fully turned up via keys (and therefore at 0x01),
then setting to 0xff with setpci doesn't turn it off. At all other
key steps it does. :-)
> If above is true, then you have a very particular notebook that
> reverse the sense of the LPBC values I don't know who ever came
> across such device. wow.
Maybe they screwed it up and therefore sold it with Linux ("linpus")
and a custom driver preinstalled ...
> Regarding that your brightness control key, due to that it is
> controlled by acer_wmi and likely that BIOS aware this, it would do
> brightness in a reversed way.
acer_wmi doesn't do the brightness adjustment. But maybe under "linpus"
some variant of it did. (BTW: there are two keys on this notebook that
aren't handled by the kernel, by X11 or even acer_wmi. There are just no
events for them. Looks like another ACER brain damage err.. "capability". :-)
m.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #13 from gottfried.haider at gmail.com 2011-05-17 13:35:25 PDT --- http://www.youtube.com/watch?v=rywJs08LoKk -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #12 from gottfried.haider at gmail.com 2011-05-17 13:32:22 PDT --- I can't rule out that they do something but I am still seeing it. It seems to be rather connected to certain geometries/textures than a global thing (at least now) - for example there is a position in the map where the weapon flickers, making a texture beneath visible. Uploading the last video of the day.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #11 from Alex Deucher 2011-05-17 13:05:09 PDT --- You might try these patches as well: http://lists.freedesktop.org/archives/xorg-devel/2011-May/021907.html http://lists.freedesktop.org/archives/xorg-devel/2011-May/021909.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #10 from gottfried.haider at gmail.com 2011-05-17 12:58:33 PDT --- I compiled xserver-xorg from xorg-edgers ppa with the patch applied, and unless there is more to it than replacing libdri2.so with the newly compiled version this does _not_ fix the issue for me. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[2.6.39-rc7] i915: kworker busily spinning...
With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9), sometimes I find one of the kworker threads busily running with 15-20% system time for some minutes, causing terrible interactivity latency. I've seen it occur when plugging eg a HDMI display, and also when no display has been plugged (ie only the internal LVDS connection is active). Across multiple kernel task captures, I see the kernel thread consistently reading one of the connector's EDID data [1]; I guess either it's having a hard time reading from a disconnected connector and retrying, or is incorrectly detecting a change when there is none. I'll enable DRM debugging to see what connectors it believes it needs to read from. Anything else that would be handy to capture, or any thoughts? Also, the 100ms connector change polling seems overkill, particularly when power consumption is important; 1000-2000ms would be sufficient, do you think? Thanks, Daniel --- [1] kworker/2:2 R running task 504886 2 0x 0002 88021e804040 88021e85f9b0 88021e804040 88021e85e000 4000 8802210a4040 88021e804040 0046 81c18b20 88022106c000 8270b740 Call Trace: [] ? mark_held_locks+0x70/0xa0 [] ? get_parent_ip+0x11/0x50 [] ? sub_preempt_count+0x9d/0xd0 [] schedule_timeout+0x175/0x250 [] ? run_timer_softirq+0x2a0/0x2a0 [] schedule_timeout_uninterruptible+0x19/0x20 [] msleep+0x18/0x20 [] gmbus_xfer+0x400/0x620 [i915] [] i2c_transfer+0xa2/0xf0 [] drm_do_probe_ddc_edid+0x66/0xa0 [drm] [] drm_get_edid+0x29/0x60 [drm] [] intel_hdmi_detect+0x56/0xe0 [i915] [] output_poll_execute+0xd7/0x1a0 [drm_kms_helper] [] process_one_work+0x1a4/0x450 [] ? process_one_work+0x146/0x450 [] ? drm_helper_disable_unused_functions+0x150/0x150 [drm_kms_helper] [] process_scheduled_works+0x2c/0x40 [] worker_thread+0x284/0x350 [] ? manage_workers.clone.23+0x120/0x120 [] kthread+0xb6/0xc0 [] ? trace_hardirqs_on_caller+0x13d/0x180 [] kernel_thread_helper+0x4/0x10 [] ? finish_task_switch+0x6f/0x100 [] ? retint_restore_args+0xe/0xe [] ? __init_kthread_worker+0x70/0x70 [] ? gs_change+0xb/0xb -- Daniel J Blueman
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #9 from Alex Deucher 2011-05-17 11:59:48 PDT --- This is probably a duplicate of bug 35452. Does the xserver patch there help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #8 from gottfried.haider at gmail.com 2011-05-17 11:31:08 PDT --- Created an attachment (id=46837) --> (https://bugs.freedesktop.org/attachment.cgi?id=46837) xorg.log from booting current xorg-edgers ppa with page flip disabled -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #7 from gottfried.haider at gmail.com 2011-05-17 11:30:18 PDT --- Created an attachment (id=46836) --> (https://bugs.freedesktop.org/attachment.cgi?id=46836) dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #6 from gottfried.haider at gmail.com 2011-05-17 11:29:02 PDT --- Disabling page flip indeed fixes the flickering in both games. I am attaching both files you requested (from my boot with page flip disabled). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37296] New: [r600g] lightning artifacts on frozenbyte games
https://bugs.freedesktop.org/show_bug.cgi?id=37296 Summary: [r600g] lightning artifacts on frozenbyte games Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: a.heider at gmail.com Created an attachment (id=46835) --> (https://bugs.freedesktop.org/attachment.cgi?id=46835) screenshot On a x86-64 host with a HD3870 running 2.6.39-2-generic (from ubuntu's oneiric) and libdrm-2.4.25 and mesa compiled for 32bit: OpenGL renderer string: Gallium 0.4 on AMD RV670 OpenGL version string: 2.1 Mesa 7.11-devel (git-390196e) I get lightning artifacts with r600g on a couple of games from frozenbyte.com, most notably when using the flashlight in shadowgrounds. Here's a apitrace capture: http://static.hackmii.com/dhewg/shadowgrounds.apitrace.xz When replaying it via glretrace there're some weird window resizes, but the issue is visible when it doesn't crash :) The issue does not exist with swrast. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #5 from Alex Deucher 2011-05-17 11:13:05 PDT --- Please attach your xorg log and dmesg output as well. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #4 from Alex Deucher 2011-05-17 11:11:24 PDT --- Does: Option "EnablePageFlip" "FALSE" in the device section of your xorg.conf fix the flickering? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #3 from gottfried.haider at gmail.com 2011-05-17 11:08:01 PDT --- that's on current xorg-edgers ppa: http://www.youtube.com/watch?v=OPnDxJoOW6g -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #2 from gottfried.haider at gmail.com 2011-05-17 10:59:40 PDT --- I installed xorg-edgers and the stripes are gone now! Can anyone point me to the commit that fixed that? The flickering still occurs on OpenArena and Armagetron. Can this be an ordinary vsync thing? (I haven't changed anything in my xorg.conf or so.) Uploading a new video.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
i915/kms/backlight-combo mode problem
* Michael Chang -- Tuesday 17 May 2011:
[LBPC]
> You can know your LPBC value by:
> $ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}'
>
> And alter it's value via setpci (assuming set it to max)
> $ setpci -s 00:02.0 F4.B=ff
>
> I assume you've tried this .. as you report setpci works for you. :)
Ahh, yes, indeed. This lspci line (almost) always shows a value that
corresponds with the actual backlight brightness, and both lines work
with and without acpi_osi=Linux. (Whereas adjustment via keys only works
*with* acpi_osi=Linux.) (Tested with 2.6.39-rc7/bd1a643e10)
> Could you help to get the LPBC value in the initial dark condition? If
> it's not corresponds to 255, maybe something sneaks and changes it but
> not logged.
Initially (with acpi_osi=Linux) LPBC=0xff. After "brightness down"
it's 0x19, and after then pressing "brightness up" it's 0x01. The lowest
value I can achieve after pressing "brightness down" a few times is 0xe5,
the highest is 0x01. Neither 0xff nor 0x00 can be reached via keys, but
can (most of the time -- see below!) be set with the setpci line and give
the expected results, backlight off and fully on. ("display toggle" has
no effect on LBPC, btw.)
Setting 0xFF doesn't always turn the backlight off, though! If LBPC is
at the (key) maximum 0x01, then setting 0xFF via setpci changes only the
LBPC value as shown by lspci, but the backlight isn't actually turned off!
If I then press "backlight darker" once (LBPC=0x19), then setting 0xFF
via setpci works again.
> 1. $ dmesg -c
> 2. Close the lid
> 3. Open the lid
> 4. $ dmesg > dmesg.lid
The results are:
[ 188.571040] [drm:intel_panel_set_backlight], set backlight PWM = 736950
[ 188.571048] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE =
1073741824
[ 188.571054] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE =
1073741824
[ 188.571059] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[ 188.571064] [drm:intel_panel_set_backlight], set backlight max = 736950
[ 188.571069] [drm:intel_panel_set_backlight], set backlight lbpc = 255
[ 188.571075] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040
[ 188.571080] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[ 188.571084] [drm:intel_panel_set_backlight],
[ 188.571088] [drm:intel_opregion_asle_intr], non asle set request??
[ 188.571093] set backlight level = 2890
The backlight is off now, as always after closing/reopening the lid,
and LPBC=0xff.
m.
PS: I'd be willing to join an irc.freenode.net channel in case you or
anyone else wants quicker ("live") responses to such queries.
[Bug 36753] Some textures now rendered as completely black after register allocator rewrite.
https://bugs.freedesktop.org/show_bug.cgi?id=36753 --- Comment #8 from Chris Rankin 2011-05-17 10:14:40 PDT --- Created an attachment (id=46833) --> (https://bugs.freedesktop.org/attachment.cgi?id=46833) Output of RADEON_DEBUG=nohiz,fp (In reply to comment #7) > Can you try this patch? That seems to have fixed it, thanks. I've attached the RADEON_DEBUG output anyway, so that you can check that it did what you were expecting. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 17-05-2011 09:49, Mauro Carvalho Chehab escreveu:
> Em 15-05-2011 18:10, Hans Verkuil escreveu:
>> On Saturday, May 14, 2011 13:46:03 Mauro Carvalho Chehab wrote:
>>> Em 14-05-2011 13:02, Hans Verkuil escreveu:
On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote:
>>>
> So, based at all I've seen, I'm pretty much convinced that the normal MMAP
> way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's)
> are not the best way to share data with framebuffers.
I agree with that, but it is a different story between two V4L2 devices.
There
you obviously want to use the streaming ioctls and still share buffers.
>>>
>>> I don't think so. the requirement for syncing the framebuffer between the
>>> two
>>> V4L2 devices is pretty much the same as we have with one V4L2 device and
>>> one GPU.
>>>
>>> On both cases, the requirement is to pass a framebuffer between two
>>> entities,
>>> and not a video stream.
>>>
>>> For example, imagine something like:
>>>
>>> V4L2 camera => V4L2 encoder t MPEG2
>>> ||
>>> LL==> GPU
>
> For the sake of clarity on my next comments, I'm naming the "V4L2 camera"
> buffer
> write endpoint as "producer" and the 2 buffer read endpoints as "consumers".
>>>
>>> Both GPU and the V4L2 encoder should use the same logic to be sure that
>>> they will
>>> use a buffer that were filled already by the camera. Also, the V4L2 camera
>>> driver can't re-use such framebuffer before being sure that both consumers
>>> has already stopped using it.
>>
>> No. A camera whose output is sent to a resizer and then to a SW/FW/HW encoder
>> is a typical example where you want to queue/dequeue buffers.
>
> Why? On a framebuffer-oriented set of ioctl's, some kernel internal calls will
> need to take care of the buffer usage, in order to be sure when a buffer can
> be rewritten, as userspace has no way to know when a buffer needs to be
> queued/dequeued.
>
> In other words, the framebuffer kernel API will probably be using a kernel
> structure like:
>
> struct v4l2_fb_handler {
> bool has_finished; /* Marks when a handler
> finishes to handle the buffer */
> bool is_producer; /* Used by the handler
> that writes data into the buffer */
>
> struct list_head *handlers; /* List with all
> handlers */
>
> void (*qbuf)(struct v4l2_fb_handler *handler); /* qbuf-like callback,
> called after having a buffer filled */
>
> v4l2_buffer_ID buf;/* Buffer ID (or
> filehandler?) - In practice, it will probably be a list with the available
> buffers */
>
> void *priv; /* handler priv data */
> }
>
> While stream is on, a kernel logic will run a loop, doing basically the steps
> bellow:
>
> 1) Wait for the producer to rise the has_finished flag;
>
> 2) call qbuf() for all consumers. The qbuf() call shouldn't block; it
> just calls
> a per-handler logic to start using that buffer;
>
> 3) When each fb handler finishes using its buffer, it will rise
> has_finished flag;
>
> 4) After having all buffer handlers marked as has_finished, cleans the
> has_finished
> flags and re-queue the buffer.
>
> Step (2) is equivalent to VIDIOC_QBUF, and step (4) is equivalent to
> VIDIOC_DQBUF.
>
> PS.: The above is just a simplified view of such handler. We'll probably need
> more steps. For
> example, between (1) and (2) it may probably need some logic to check if is
> there an available
> empty buffer. If not, create a new one and use it.
>
> What happens with REQBUF/QBUF/DQBUF is that:
> - with those calls, there's just one buffer consumer, and just one
> buffer producer;
> - either the producer or the consumer is on userspace, and the other
> pair is
> at kernelspace;
> - buffers are allocated before the start of a process, via an explicit
> call;
> - buffers need to be mmapped, in order to be visible at userspace.
>
> None of the above applies to a framebuffer-oriented API:
> - more than one buffer consumer is allowed;
> - consumers and producers are on kernelspace (it might be needed to
> have an
> an API for handling such buffers also on userspace, although it doesn't sound
> a good
> idea to me, IMHO);
A side note: in the specific case of X server and display drivers, such
kernelspace-userspace
API for buffers already exists. I don't know DRI/GEM/KMS enough to tell
exactly how this work
or if it will require some changes or not, in order to work like the above, but
it seems that
the right approach is to try to use or extend the existing API's, instead of
creating
something new.
The main point is: DQBUF/QBUF API assumes that userspace has full control at
the buffer usage,
and buffer is handled at userspace (so, they
[Bug 36421] RV710: GPU lockup running portal2 in wine.
https://bugs.freedesktop.org/show_bug.cgi?id=36421 --- Comment #6 from Tobias Jakobi 2011-05-17 09:57:27 PDT --- This issue was already present long before this particular commit, at least for me. It's also not strictly related to the HL2 engine, since I get the exact same problem with FEAR and its DX9 level renderpath. I presume that r600g currently doesn't handle shader code that well that gets build by wined3d for certain shader configurations. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #1 from Michel D?nzer 2011-05-17 09:49:07 PDT --- Does this still happen with r600g from current upstream Mesa Git master? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 15-05-2011 18:10, Hans Verkuil escreveu:
> On Saturday, May 14, 2011 13:46:03 Mauro Carvalho Chehab wrote:
>> Em 14-05-2011 13:02, Hans Verkuil escreveu:
>>> On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote:
>>
So, based at all I've seen, I'm pretty much convinced that the normal MMAP
way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's)
are not the best way to share data with framebuffers.
>>>
>>> I agree with that, but it is a different story between two V4L2 devices.
>>> There
>>> you obviously want to use the streaming ioctls and still share buffers.
>>
>> I don't think so. the requirement for syncing the framebuffer between the two
>> V4L2 devices is pretty much the same as we have with one V4L2 device and one
>> GPU.
>>
>> On both cases, the requirement is to pass a framebuffer between two
>> entities,
>> and not a video stream.
>>
>> For example, imagine something like:
>>
>> V4L2 camera => V4L2 encoder t MPEG2
>> ||
>> LL==> GPU
For the sake of clarity on my next comments, I'm naming the "V4L2 camera" buffer
write endpoint as "producer" and the 2 buffer read endpoints as "consumers".
>>
>> Both GPU and the V4L2 encoder should use the same logic to be sure that they
>> will
>> use a buffer that were filled already by the camera. Also, the V4L2 camera
>> driver can't re-use such framebuffer before being sure that both consumers
>> has already stopped using it.
>
> No. A camera whose output is sent to a resizer and then to a SW/FW/HW encoder
> is a typical example where you want to queue/dequeue buffers.
Why? On a framebuffer-oriented set of ioctl's, some kernel internal calls will
need to take care of the buffer usage, in order to be sure when a buffer can
be rewritten, as userspace has no way to know when a buffer needs to be
queued/dequeued.
In other words, the framebuffer kernel API will probably be using a kernel
structure like:
struct v4l2_fb_handler {
bool has_finished; /* Marks when a handler
finishes to handle the buffer */
bool is_producer; /* Used by the handler
that writes data into the buffer */
struct list_head *handlers; /* List with all
handlers */
void (*qbuf)(struct v4l2_fb_handler *handler); /* qbuf-like callback,
called after having a buffer filled */
v4l2_buffer_ID buf;/* Buffer ID (or
filehandler?) - In practice, it will probably be a list with the available
buffers */
void *priv; /* handler priv data */
}
While stream is on, a kernel logic will run a loop, doing basically the steps
bellow:
1) Wait for the producer to rise the has_finished flag;
2) call qbuf() for all consumers. The qbuf() call shouldn't block; it
just calls
a per-handler logic to start using that buffer;
3) When each fb handler finishes using its buffer, it will rise
has_finished flag;
4) After having all buffer handlers marked as has_finished, cleans the
has_finished
flags and re-queue the buffer.
Step (2) is equivalent to VIDIOC_QBUF, and step (4) is equivalent to
VIDIOC_DQBUF.
PS.: The above is just a simplified view of such handler. We'll probably need
more steps. For
example, between (1) and (2) it may probably need some logic to check if is
there an available
empty buffer. If not, create a new one and use it.
What happens with REQBUF/QBUF/DQBUF is that:
- with those calls, there's just one buffer consumer, and just one
buffer producer;
- either the producer or the consumer is on userspace, and the other
pair is
at kernelspace;
- buffers are allocated before the start of a process, via an explicit
call;
- buffers need to be mmapped, in order to be visible at userspace.
None of the above applies to a framebuffer-oriented API:
- more than one buffer consumer is allowed;
- consumers and producers are on kernelspace (it might be needed to
have an
an API for handling such buffers also on userspace, although it doesn't sound a
good
idea to me, IMHO);
- buffers can be dynamically allocated/de-allocated;
- buffers don't need to be mmapped to userspace.
> Especially since
> the various parts of the pipeline may stall for a bit so you don't want to
> lose
> frames. That's not what the overlay API is for, that's what our streaming API
> gives us.
>
> The use case above isn't even possible without copying. At least, I don't see
> a
> way, unless the GPU buffer is non-destructive. In that case you can give the
> frame to the GPU, and when the GPU is finished you can give it to the encoder.
> I suspect that might become quite complex though.
Well, if some fb consumers would also be rewriting the buffers, serializing
them is
needed, as you can't allow another
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 Michel D?nzer changed: What|Removed |Added Product|xorg|Mesa Component|Driver/Radeon |Drivers/Gallium/r600 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QAContact|xorg-team at lists.x.org | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #45 from Travis Glenn Hansen 2011-05-17 08:11:35 PDT --- I just wanted to note that EFI is out of the picture in my setup. Both laptop and monitor in my case are Dell. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
No subject
and actual brightness is maximum (255*2890=736950). I see no other change after it until manual brightness change. This is a totally reversed to your problem. Could you help to get the LPBC value in the initial dark condition? If it's not corresponds to 255, maybe something sneaks and changes it but not logged. [3.125522] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [3.125525] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [3.125527] [drm:intel_panel_set_backlight], set backlight PWM = 736950 [3.125529] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [3.125531] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [3.125533] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [3.125535] [drm:intel_panel_set_backlight], set backlight max = 736950 [3.125537] [drm:intel_panel_set_backlight], set backlight lbpc = 255 [3.125544] [drm:intel_panel_set_backlight], set backlight level = 2890 > Yes, that's the case. (Except that after closing the lid it's off again.) Maybe this is another clue for root cause. Would it be convenient for you to gather the log? 1. $ dmesg -c 2. Close the lid 3. Open the lid 4. $ dmesg > dmesg.lid Thanks a lot, Michael Chang
[Bug 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 --- Comment #7 from Pierre-Eric Pelloux-Prayer 2011-05-17 05:33:51 PDT --- Created an attachment (id=46804) View: https://bugs.freedesktop.org/attachment.cgi?id=46804 Review: https://bugs.freedesktop.org/review?bug=37142=46804 vertex buffer upload caching Here's a patch adding vertex buffer upload caching. It's not extensively tested (only with custom app and openarena), and is a bit hackish (mainly regarding : ctx->Array.NewState field, but it seems unused elsewhere). Anyway, it allowed me to do some testing and confirm the initial guess : it brings no performance improvements to openarena :-/ (but that was expected, as profiling the game tells that u_upload_data < 1% cpu time) So I guess the handling of EXT_compiled_vertex_array is useless - maybe with 1 exception : lower end video cards with lower bandwidth ? I can't test this scenario here, as I only have AMD HD4850. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 2/2] drm/radeon/kms: simplify r6xx blit code
Covert 4k pages to multiples of 64x64x4 tiles.
This is also more efficient than a scanline based
approach from the MC's perspective.
Signed-off-by: Alex Deucher
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/r600.c |4 +-
drivers/gpu/drm/radeon/r600_blit_kms.c | 276
drivers/gpu/drm/radeon/radeon_asic.h |4 +-
3 files changed, 109 insertions(+), 175 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 334aee6..9fc6844 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2363,14 +2363,14 @@ int r600_copy_blit(struct radeon_device *rdev,
mutex_lock(>r600_blit.mutex);
rdev->r600_blit.vb_ib = NULL;
- r = r600_blit_prepare_copy(rdev, num_pages * RADEON_GPU_PAGE_SIZE);
+ r = r600_blit_prepare_copy(rdev, num_pages);
if (r) {
if (rdev->r600_blit.vb_ib)
radeon_ib_free(rdev, >r600_blit.vb_ib);
mutex_unlock(>r600_blit.mutex);
return r;
}
- r600_kms_blit_copy(rdev, src_offset, dst_offset, num_pages *
RADEON_GPU_PAGE_SIZE);
+ r600_kms_blit_copy(rdev, src_offset, dst_offset, num_pages);
r600_blit_done_copy(rdev, fence);
mutex_unlock(>r600_blit.mutex);
return 0;
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index 9aa74c3..d9994c9 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -42,6 +42,10 @@
#define COLOR_5_6_5 0x8
#define COLOR_8_8_8_8 0x1a
+#define RECT_UNIT_H 32
+#define RECT_UNIT_W (RADEON_GPU_PAGE_SIZE / 4 / RECT_UNIT_H)
+#define MAX_RECT_DIM 8192
+
/* emits 21 on rv770+, 23 on r600 */
static void
set_render_target(struct radeon_device *rdev, int format,
@@ -600,13 +604,59 @@ static void r600_vb_ib_put(struct radeon_device *rdev)
radeon_ib_free(rdev, >r600_blit.vb_ib);
}
-int r600_blit_prepare_copy(struct radeon_device *rdev, int size_bytes)
+/* FIXME: the function is very similar to evergreen_blit_create_rect, except
+ that it different predefined constants; consider commonizing */
+static unsigned r600_blit_create_rect(unsigned num_pages, int *width, int
*height)
+{
+ unsigned max_pages;
+ unsigned pages = num_pages;
+ int w, h;
+
+ if (num_pages == 0) {
+ /* not supposed to be called with no pages, but just in case */
+ h = 0;
+ w = 0;
+ pages = 0;
+ WARN_ON(1);
+ } else {
+ int rect_order = 2;
+ h = RECT_UNIT_H;
+ while (num_pages / rect_order) {
+ h *= 2;
+ rect_order *= 4;
+ if (h >= MAX_RECT_DIM) {
+ h = MAX_RECT_DIM;
+ break;
+ }
+ }
+ max_pages = (MAX_RECT_DIM * h) / (RECT_UNIT_W * RECT_UNIT_H);
+ if (pages > max_pages)
+ pages = max_pages;
+ w = (pages * RECT_UNIT_W * RECT_UNIT_H) / h;
+ w = (w / RECT_UNIT_W) * RECT_UNIT_W;
+ pages = (w * h) / (RECT_UNIT_W * RECT_UNIT_H);
+ BUG_ON(pages == 0);
+ }
+
+
+ DRM_DEBUG("blit_rectangle: h=%d, w=%d, pages=%d\n", h, w, pages);
+
+ /* return width and height only of the caller wants it */
+ if (height)
+ *height = h;
+ if (width)
+ *width = w;
+
+ return pages;
+}
+
+
+int r600_blit_prepare_copy(struct radeon_device *rdev, unsigned num_pages)
{
int r;
- int ring_size, line_size;
- int max_size;
+ int ring_size;
/* loops of emits 64 + fence emit possible */
- int dwords_per_loop = 76, num_loops;
+ int dwords_per_loop = 76, num_loops = 0;
r = r600_vb_ib_get(rdev);
if (r)
@@ -616,18 +666,12 @@ int r600_blit_prepare_copy(struct radeon_device *rdev,
int size_bytes)
if (rdev->family > CHIP_R600 && rdev->family < CHIP_RV770)
dwords_per_loop += 2;
- /* 8 bpp vs 32 bpp for xfer unit */
- if (size_bytes & 3)
- line_size = 8192;
- else
- line_size = 8192*4;
-
- max_size = 8192 * line_size;
+ /* num loops */
+ while (num_pages) {
+ num_pages -= r600_blit_create_rect(num_pages, NULL, NULL);
+ num_loops++;
+ }
- /* major loops cover the max size transfer */
- num_loops = ((size_bytes + max_size) / max_size);
- /* minor loops cover the extra non aligned bits */
- num_loops += ((size_bytes % line_size) ? 1 : 0);
/* calculate number of loops correctly */
ring_size = num_loops * dwords_per_loop;
/* set default + shaders */
@@ -659,182
[PATCH 1/2] drm/radeon/kms: simplify evergreen blit code
Covert 4k pages to multiples of 64x64x4 tiles.
This is also more efficient than a scanline based
approach from the MC's perspective.
Signed-off-by: Alex Deucher
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen.c |4 +-
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 295 +++
drivers/gpu/drm/radeon/radeon_asic.h|4 +-
3 files changed, 123 insertions(+), 180 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 5df39bf..5f0ecc7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3180,14 +3180,14 @@ int evergreen_copy_blit(struct radeon_device *rdev,
mutex_lock(>r600_blit.mutex);
rdev->r600_blit.vb_ib = NULL;
- r = evergreen_blit_prepare_copy(rdev, num_pages * RADEON_GPU_PAGE_SIZE);
+ r = evergreen_blit_prepare_copy(rdev, num_pages);
if (r) {
if (rdev->r600_blit.vb_ib)
radeon_ib_free(rdev, >r600_blit.vb_ib);
mutex_unlock(>r600_blit.mutex);
return r;
}
- evergreen_kms_blit_copy(rdev, src_offset, dst_offset, num_pages *
RADEON_GPU_PAGE_SIZE);
+ evergreen_kms_blit_copy(rdev, src_offset, dst_offset, num_pages);
evergreen_blit_done_copy(rdev, fence);
mutex_unlock(>r600_blit.mutex);
return 0;
diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index 2eb2518..3b24137 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -44,6 +44,10 @@
#define COLOR_5_6_5 0x8
#define COLOR_8_8_8_8 0x1a
+#define RECT_UNIT_H 32
+#define RECT_UNIT_W (RADEON_GPU_PAGE_SIZE / 4 / RECT_UNIT_H)
+#define MAX_RECT_DIM 16384
+
/* emits 17 */
static void
set_render_target(struct radeon_device *rdev, int format,
@@ -56,7 +60,7 @@ set_render_target(struct radeon_device *rdev, int format,
if (h < 8)
h = 8;
- cb_color_info = ((format << 2) | (1 << 24) | (1 << 8));
+ cb_color_info = ((format << 2) | (1 << 24) | (2 << 8));
pitch = (w / 8) - 1;
slice = ((w * h) / 64) - 1;
@@ -67,7 +71,7 @@ set_render_target(struct radeon_device *rdev, int format,
radeon_ring_write(rdev, slice);
radeon_ring_write(rdev, 0);
radeon_ring_write(rdev, cb_color_info);
- radeon_ring_write(rdev, (1 << 4));
+ radeon_ring_write(rdev, 0);
radeon_ring_write(rdev, (w - 1) | ((h - 1) << 16));
radeon_ring_write(rdev, 0);
radeon_ring_write(rdev, 0);
@@ -179,7 +183,7 @@ set_tex_resource(struct radeon_device *rdev,
sq_tex_resource_word0 = (1 << 0); /* 2D */
sq_tex_resource_word0 |= pitch >> 3) - 1) << 6) |
((w - 1) << 18));
- sq_tex_resource_word1 = ((h - 1) << 0) | (1 << 28);
+ sq_tex_resource_word1 = ((h - 1) << 0) | (2 << 28);
/* xyzw swizzles */
sq_tex_resource_word4 = (0 << 16) | (1 << 19) | (2 << 22) | (3 << 25);
@@ -751,30 +755,80 @@ static void evergreen_vb_ib_put(struct radeon_device
*rdev)
radeon_ib_free(rdev, >r600_blit.vb_ib);
}
-int evergreen_blit_prepare_copy(struct radeon_device *rdev, int size_bytes)
+
+/* maps the rectangle to the buffer so that satisfies the following properties:
+ * - dimensions are less or equal to the hardware limit (MAX_RECT_DIM)
+ * - rectangle consists of integer number of pages
+ * - height is an integer multiple of RECT_UNIT_H
+ * - width is an integer multiple of RECT_UNIT_W
+ * - (the above three conditions also guarantee tile-aligned size)
+ * - it is as square as possible (sides ratio never greater than 2:1)
+ * - uses maximum number of pages that fit the above constraints
+ *
+ * input: buffer size, pointers to width/height variables
+ * return: number of pages that were successfully mapped to the rectangle
+ * width/height of the rectangle
+ */
+static unsigned evergreen_blit_create_rect(unsigned num_pages, int *width, int
*height)
+{
+ unsigned max_pages;
+ unsigned pages = num_pages;
+ int w, h;
+
+ if (num_pages == 0) {
+ /* not supposed to be called with no pages, but just in case */
+ h = 0;
+ w = 0;
+ pages = 0;
+ WARN_ON(1);
+ } else {
+ int rect_order = 2;
+ h = RECT_UNIT_H;
+ while (num_pages / rect_order) {
+ h *= 2;
+ rect_order *= 4;
+ if (h >= MAX_RECT_DIM) {
+ h = MAX_RECT_DIM;
+ break;
+ }
+ }
+ max_pages = (MAX_RECT_DIM * h) / (RECT_UNIT_W * RECT_UNIT_H);
+ if (pages > max_pages)
+
[Bug 26891] Radeon KMS on Macs with EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #6 from Ortwin Gl?ck 2011-05-17 04:14:24 PDT --- Sorry for being slightly off-topic. I was implicitly referring to bug 27314, where I observe the same problem "radeon :01:00.0: Invalid ROM contents" when booting in legacy mode (where we obviously do have a vbios). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26891] Radeon KMS on Macs with EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #5 from shirk at bitspin.org 2011-05-17 03:31:16 PDT --- (In reply to comment #4) I assume you're not familiar with mac or didn't read the while bug history. Mac are booted using the EFI runtime one of the successors to BIOS. > What is the real reason that the driver doesn't see the video BIOS? Is it > looking at the wrong address? Is some MMU wrongly setup? I mean the video BIOS > is obviously there, You're wrong here. The bios is there if you boot in 'legacy mode'. Legacy mode means your EFI machine will load and run a (slow) BIOS emulation. > if you can extract it with dd. This exact step happens in legacy mode. If you boot in native EFI you don't have any BIOS at all. > I would rather see the real > bug fixed than have a workaround. As nice as it sounds 'fixing' would imply writing a separate KMS driver which would work entirely without the need to access the BIOS. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #17 from Milan Plzik 2011-05-17 03:01:25 PDT --- (In reply to comment #16) > Nope, I've run out of ideas and I don't have the GPU. > > (Milan, are you near Brno by any chance?) I'll contact you by e-mail and we'll see whether we can arrange a meeting. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26891] Radeon KMS on Macs with EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #4 from Ortwin Gl?ck 2011-05-17 02:50:40 PDT --- What is the real reason that the driver doesn't see the video BIOS? Is it looking at the wrong address? Is some MMU wrongly setup? I mean the video BIOS is obviously there, if you can extract it with dd. I would rather see the real bug fixed than have a workaround. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #44 from Ortwin Gl?ck 2011-05-17 02:45:27 PDT --- But I also noticed the line "radeon :01:00.0: Invalid ROM contents" in my dmesg. Although I am not using EFI boot (plain old grub without EFI support), this indicates that the kernel doesn't see a valid video BIOS, right? So I doubt this bug as anything to do with DP link training actually, and bug 26891 is really the cause. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36753] Some textures now rendered as completely black after register allocator rewrite.
https://bugs.freedesktop.org/show_bug.cgi?id=36753 --- Comment #7 from Tom Stellard 2011-05-17 00:59:25 PDT --- Created an attachment (id=46792) View: https://bugs.freedesktop.org/attachment.cgi?id=46792 Review: https://bugs.freedesktop.org/review?bug=36753=46792 Possible Fix Can you try this patch. If it doesn't fix the issue, can you post the output of RADEON_DEBUG=fp again. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35192] BUG() in radeon driver with ATI Technologies Inc RV515 [Radeon X1300]
https://bugzilla.kernel.org/show_bug.cgi?id=35192 --- Comment #1 from Anthony Basile 2011-05-16 23:38:38 --- Bisecting shows that reverting 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 fixed the problem. The patch is in comment 28 of the Gentoo bug report. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915/kms/backlight-combo mode problem
2011/5/16 Melchior FRANZ melchior.fr...@gmail.com:
I don't even know what an LBPC is, other than a variable named like that.
So I'd need a hint for how to test that.
It resides at your vga adapter's pci configuration space, offset 0xf4.
You can know your LPBC value by:
$ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}'
And alter it's value via setpci (assuming set it to max)
$ setpci -s 00:02.0 F4.B=ff
I assume you've tried this .. as you report setpci works for you. :)
From your new attached log, In booting phase your LPBC is set to 255
and actual brightness is maximum (255*2890=736950). I see no other
change after it until manual brightness change. This is a totally
reversed to your problem.
Could you help to get the LPBC value in the initial dark condition? If
it's not corresponds to 255, maybe something sneaks and changes it but
not logged.
[3.125522] [drm:is_backlight_combination_mode],
BLM_COMBINATION_MODE = 1073741824
[3.125525] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[3.125527] [drm:intel_panel_set_backlight], set backlight PWM = 736950
[3.125529] [drm:is_backlight_combination_mode],
BLM_COMBINATION_MODE = 1073741824
[3.125531] [drm:is_backlight_combination_mode],
BLM_COMBINATION_MODE = 1073741824
[3.125533] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[3.125535] [drm:intel_panel_set_backlight], set backlight max = 736950
[3.125537] [drm:intel_panel_set_backlight], set backlight lbpc = 255
[3.125544] [drm:intel_panel_set_backlight], set backlight level = 2890
Yes, that's the case. (Except that after closing the lid it's off again.)
Maybe this is another clue for root cause. Would it be convenient for
you to gather the log?
1. $ dmesg -c
2. Close the lid
3. Open the lid
4. $ dmesg dmesg.lid
Thanks a lot,
Michael Chang
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36753] Some textures now rendered as completely black after register allocator rewrite.
https://bugs.freedesktop.org/show_bug.cgi?id=36753 --- Comment #7 from Tom Stellard tstel...@gmail.com 2011-05-17 00:59:25 PDT --- Created an attachment (id=46792) View: https://bugs.freedesktop.org/attachment.cgi?id=46792 Review: https://bugs.freedesktop.org/review?bug=36753attachment=46792 Possible Fix Can you try this patch. If it doesn't fix the issue, can you post the output of RADEON_DEBUG=fp again. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915/kms/backlight-combo mode problem
* Michael Chang -- Tuesday 17 May 2011:
[LBPC]
You can know your LPBC value by:
$ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}'
And alter it's value via setpci (assuming set it to max)
$ setpci -s 00:02.0 F4.B=ff
I assume you've tried this .. as you report setpci works for you. :)
Ahh, yes, indeed. This lspci line (almost) always shows a value that
corresponds with the actual backlight brightness, and both lines work
with and without acpi_osi=Linux. (Whereas adjustment via keys only works
*with* acpi_osi=Linux.) (Tested with 2.6.39-rc7/bd1a643e10)
Could you help to get the LPBC value in the initial dark condition? If
it's not corresponds to 255, maybe something sneaks and changes it but
not logged.
Initially (with acpi_osi=Linux) LPBC=0xff. After brightness down
it's 0x19, and after then pressing brightness up it's 0x01. The lowest
value I can achieve after pressing brightness down a few times is 0xe5,
the highest is 0x01. Neither 0xff nor 0x00 can be reached via keys, but
can (most of the time -- see below!) be set with the setpci line and give
the expected results, backlight off and fully on. (display toggle has
no effect on LBPC, btw.)
Setting 0xFF doesn't always turn the backlight off, though! If LBPC is
at the (key) maximum 0x01, then setting 0xFF via setpci changes only the
LBPC value as shown by lspci, but the backlight isn't actually turned off!
If I then press backlight darker once (LBPC=0x19), then setting 0xFF
via setpci works again.
1. $ dmesg -c
2. Close the lid
3. Open the lid
4. $ dmesg dmesg.lid
The results are:
[ 188.571040] [drm:intel_panel_set_backlight], set backlight PWM = 736950
[ 188.571048] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE =
1073741824
[ 188.571054] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE =
1073741824
[ 188.571059] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[ 188.571064] [drm:intel_panel_set_backlight], set backlight max = 736950
[ 188.571069] [drm:intel_panel_set_backlight], set backlight lbpc = 255
[ 188.571075] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040
[ 188.571080] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[ 188.571084] [drm:intel_panel_set_backlight],
[ 188.571088] [drm:intel_opregion_asle_intr], non asle set request??
[ 188.571093] set backlight level = 2890
The backlight is off now, as always after closing/reopening the lid,
and LPBC=0xff.
m.
PS: I'd be willing to join an irc.freenode.net channel in case you or
anyone else wants quicker (live) responses to such queries.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #44 from Ortwin Glück o...@odi.ch 2011-05-17 02:45:27 PDT --- But I also noticed the line radeon :01:00.0: Invalid ROM contents in my dmesg. Although I am not using EFI boot (plain old grub without EFI support), this indicates that the kernel doesn't see a valid video BIOS, right? So I doubt this bug as anything to do with DP link training actually, and bug 26891 is really the cause. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS on Macs with EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #4 from Ortwin Glück o...@odi.ch 2011-05-17 02:50:40 PDT --- What is the real reason that the driver doesn't see the video BIOS? Is it looking at the wrong address? Is some MMU wrongly setup? I mean the video BIOS is obviously there, if you can extract it with dd. I would rather see the real bug fixed than have a workaround. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915/kms/backlight-combo mode problem
Melchior,
I want to double check with you. If you change brightness from lowest
to highest, the LPBC value changes this way
Highest Lowest
0x10 , 0x19 .. 0xe5
And vice versa, from Lowest to Highest
Lowest Highest
0xe5 , .. 0x19 0x10
If above is true, then you have a very particular notebook that
reverse the sense of the LPBC values I don't know who ever came
across such device. wow.
Regarding that your brightness control key, due to that it is
controlled by acer_wmi and likely that BIOS aware this, it would do
brightness in a reversed way. I think Joey would check DSDT and see
any clue or evidence for this. OTOH the i915 driver didn't aware of
this and operates as usual sense that means falling into the trap.
PS. I see your log always reverse the sense of this LPBC value, now I
know why. :)
Regards,
Michael Chang
2011/5/17 Melchior FRANZ melchior.fr...@gmail.com:
* Michael Chang -- Tuesday 17 May 2011:
[LBPC]
You can know your LPBC value by:
$ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}'
And alter it's value via setpci (assuming set it to max)
$ setpci -s 00:02.0 F4.B=ff
I assume you've tried this .. as you report setpci works for you. :)
Ahh, yes, indeed. This lspci line (almost) always shows a value that
corresponds with the actual backlight brightness, and both lines work
with and without acpi_osi=Linux. (Whereas adjustment via keys only works
*with* acpi_osi=Linux.) (Tested with 2.6.39-rc7/bd1a643e10)
Could you help to get the LPBC value in the initial dark condition? If
it's not corresponds to 255, maybe something sneaks and changes it but
not logged.
Initially (with acpi_osi=Linux) LPBC=0xff. After brightness down
it's 0x19, and after then pressing brightness up it's 0x01. The lowest
value I can achieve after pressing brightness down a few times is 0xe5,
the highest is 0x01. Neither 0xff nor 0x00 can be reached via keys, but
can (most of the time -- see below!) be set with the setpci line and give
the expected results, backlight off and fully on. (display toggle has
no effect on LBPC, btw.)
Setting 0xFF doesn't always turn the backlight off, though! If LBPC is
at the (key) maximum 0x01, then setting 0xFF via setpci changes only the
LBPC value as shown by lspci, but the backlight isn't actually turned off!
If I then press backlight darker once (LBPC=0x19), then setting 0xFF
via setpci works again.
1. $ dmesg -c
2. Close the lid
3. Open the lid
4. $ dmesg dmesg.lid
The results are:
[ 188.571040] [drm:intel_panel_set_backlight], set backlight PWM = 736950
[ 188.571048] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE =
1073741824
[ 188.571054] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE =
1073741824
[ 188.571059] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[ 188.571064] [drm:intel_panel_set_backlight], set backlight max = 736950
[ 188.571069] [drm:intel_panel_set_backlight], set backlight lbpc = 255
[ 188.571075] [drm:intel_panel_set_backlight], set backlight tmp(1) =
189399040
[ 188.571080] [drm:intel_panel_set_backlight], set backlight tmp(2) =
189399040
[ 188.571084] [drm:intel_panel_set_backlight],
[ 188.571088] [drm:intel_opregion_asle_intr], non asle set request??
[ 188.571093] set backlight level = 2890
The backlight is off now, as always after closing/reopening the lid,
and LPBC=0xff.
m.
PS: I'd be willing to join an irc.freenode.net channel in case you or
anyone else wants quicker (live) responses to such queries.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS on Macs with EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #5 from sh...@bitspin.org 2011-05-17 03:31:16 PDT --- (In reply to comment #4) I assume you're not familiar with mac or didn't read the while bug history. Mac are booted using the EFI runtime one of the successors to BIOS. What is the real reason that the driver doesn't see the video BIOS? Is it looking at the wrong address? Is some MMU wrongly setup? I mean the video BIOS is obviously there, You're wrong here. The bios is there if you boot in 'legacy mode'. Legacy mode means your EFI machine will load and run a (slow) BIOS emulation. if you can extract it with dd. This exact step happens in legacy mode. If you boot in native EFI you don't have any BIOS at all. I would rather see the real bug fixed than have a workaround. As nice as it sounds 'fixing' would imply writing a separate KMS driver which would work entirely without the need to access the BIOS. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS on Macs with EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #6 from Ortwin Glück o...@odi.ch 2011-05-17 04:14:24 PDT --- Sorry for being slightly off-topic. I was implicitly referring to bug 27314, where I observe the same problem radeon :01:00.0: Invalid ROM contents when booting in legacy mode (where we obviously do have a vbios). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[2.6.39-rc7] i915: kworker busily spinning...
With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9), sometimes I find one of the kworker threads busily running with 15-20% system time for some minutes, causing terrible interactivity latency. I've seen it occur when plugging eg a HDMI display, and also when no display has been plugged (ie only the internal LVDS connection is active). Across multiple kernel task captures, I see the kernel thread consistently reading one of the connector's EDID data [1]; I guess either it's having a hard time reading from a disconnected connector and retrying, or is incorrectly detecting a change when there is none. I'll enable DRM debugging to see what connectors it believes it needs to read from. Anything else that would be handy to capture, or any thoughts? Also, the 100ms connector change polling seems overkill, particularly when power consumption is important; 1000-2000ms would be sufficient, do you think? Thanks, Daniel --- [1] kworker/2:2 R running task 504886 2 0x 0002 88021e804040 88021e85f9b0 88021e804040 88021e85e000 4000 8802210a4040 88021e804040 0046 81c18b20 88022106c000 8270b740 Call Trace: [8109a460] ? mark_held_locks+0x70/0xa0 [81059261] ? get_parent_ip+0x11/0x50 [8105933d] ? sub_preempt_count+0x9d/0xd0 [81705a35] schedule_timeout+0x175/0x250 [8106ec10] ? run_timer_softirq+0x2a0/0x2a0 [81705b29] schedule_timeout_uninterruptible+0x19/0x20 [8106f878] msleep+0x18/0x20 [a017c620] gmbus_xfer+0x400/0x620 [i915] [8150c892] i2c_transfer+0xa2/0xf0 [a002bc96] drm_do_probe_ddc_edid+0x66/0xa0 [drm] [a002c0f9] drm_get_edid+0x29/0x60 [drm] [a0176f86] intel_hdmi_detect+0x56/0xe0 [i915] [a00d1177] output_poll_execute+0xd7/0x1a0 [drm_kms_helper] [81078e14] process_one_work+0x1a4/0x450 [81078db6] ? process_one_work+0x146/0x450 [a00d10a0] ? drm_helper_disable_unused_functions+0x150/0x150 [drm_kms_helper] [810790ec] process_scheduled_works+0x2c/0x40 [8107c384] worker_thread+0x284/0x350 [8107c100] ? manage_workers.clone.23+0x120/0x120 [81080ea6] kthread+0xb6/0xc0 [8109a5cd] ? trace_hardirqs_on_caller+0x13d/0x180 [8170a494] kernel_thread_helper+0x4/0x10 [8104c64f] ? finish_task_switch+0x6f/0x100 [81708bc4] ? retint_restore_args+0xe/0xe [81080df0] ? __init_kthread_worker+0x70/0x70 [8170a490] ? gs_change+0xb/0xb -- Daniel J Blueman ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915/kms/backlight-combo mode problem
Hey, * Michael Chang -- Tuesday 17 May 2011: If you change brightness from lowest to highest, the LPBC value changes this way Highest Lowest 0x10 , 0x19 .. 0xe5 Yes. (Though it's 0x01, not 0x10.) ---0xFF ... initial value and after closing/reopening lid | 0xE5 \ ... dark | 0xCC | | 0xB2 | (1)| 0x99 | | 0x7F |_key adjustable range | 0x66 | | 0x4C | | 0x33 | --0x19 | 0x01 / ... bright 0x00 ... also bright, only settable with setpci (1) is the jump that resurrects the backlight from darkness by pressing the brightness down key And again, if fully turned up via keys (and therefore at 0x01), then setting to 0xff with setpci doesn't turn it off. At all other key steps it does. :-) If above is true, then you have a very particular notebook that reverse the sense of the LPBC values I don't know who ever came across such device. wow. Maybe they screwed it up and therefore sold it with Linux (linpus) and a custom driver preinstalled ... Regarding that your brightness control key, due to that it is controlled by acer_wmi and likely that BIOS aware this, it would do brightness in a reversed way. acer_wmi doesn't do the brightness adjustment. But maybe under linpus some variant of it did. (BTW: there are two keys on this notebook that aren't handled by the kernel, by X11 or even acer_wmi. There are just no events for them. Looks like another ACER brain damage err.. capability. :-) m. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37142] Too much vertex buffers uploads
https://bugs.freedesktop.org/show_bug.cgi?id=37142 --- Comment #7 from Pierre-Eric Pelloux-Prayer pell...@gmail.com 2011-05-17 05:33:51 PDT --- Created an attachment (id=46804) View: https://bugs.freedesktop.org/attachment.cgi?id=46804 Review: https://bugs.freedesktop.org/review?bug=37142attachment=46804 vertex buffer upload caching Here's a patch adding vertex buffer upload caching. It's not extensively tested (only with custom app and openarena), and is a bit hackish (mainly regarding : ctx-Array.NewState field, but it seems unused elsewhere). Anyway, it allowed me to do some testing and confirm the initial guess : it brings no performance improvements to openarena :-/ (but that was expected, as profiling the game tells that u_upload_data 1% cpu time) So I guess the handling of EXT_compiled_vertex_array is useless - maybe with 1 exception : lower end video cards with lower bandwidth ? I can't test this scenario here, as I only have AMD HD4850. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #45 from Travis Glenn Hansen travisghan...@yahoo.com 2011-05-17 08:11:35 PDT --- I just wanted to note that EFI is out of the picture in my setup. Both laptop and monitor in my case are Dell. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Product|xorg|Mesa Component|Driver/Radeon |Drivers/Gallium/r600 AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QAContact|xorg-t...@lists.x.org | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #1 from Michel Dänzer mic...@daenzer.net 2011-05-17 09:49:07 PDT --- Does this still happen with r600g from current upstream Mesa Git master? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36421] RV710: GPU lockup running portal2 in wine.
https://bugs.freedesktop.org/show_bug.cgi?id=36421 --- Comment #6 from Tobias Jakobi liquid.a...@gmx.net 2011-05-17 09:57:27 PDT --- This issue was already present long before this particular commit, at least for me. It's also not strictly related to the HL2 engine, since I get the exact same problem with FEAR and its DX9 level renderpath. I presume that r600g currently doesn't handle shader code that well that gets build by wined3d for certain shader configurations. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #2 from gottfried.hai...@gmail.com 2011-05-17 10:59:40 PDT --- I installed xorg-edgers and the stripes are gone now! Can anyone point me to the commit that fixed that? The flickering still occurs on OpenArena and Armagetron. Can this be an ordinary vsync thing? (I haven't changed anything in my xorg.conf or so.) Uploading a new video.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #3 from gottfried.hai...@gmail.com 2011-05-17 11:08:01 PDT --- that's on current xorg-edgers ppa: http://www.youtube.com/watch?v=OPnDxJoOW6g -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #4 from Alex Deucher ag...@yahoo.com 2011-05-17 11:11:24 PDT --- Does: Option EnablePageFlip FALSE in the device section of your xorg.conf fix the flickering? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #5 from Alex Deucher ag...@yahoo.com 2011-05-17 11:13:05 PDT --- Please attach your xorg log and dmesg output as well. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37296] New: [r600g] lightning artifacts on frozenbyte games
https://bugs.freedesktop.org/show_bug.cgi?id=37296 Summary: [r600g] lightning artifacts on frozenbyte games Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: a.hei...@gmail.com Created an attachment (id=46835) -- (https://bugs.freedesktop.org/attachment.cgi?id=46835) screenshot On a x86-64 host with a HD3870 running 2.6.39-2-generic (from ubuntu's oneiric) and libdrm-2.4.25 and mesa compiled for 32bit: OpenGL renderer string: Gallium 0.4 on AMD RV670 OpenGL version string: 2.1 Mesa 7.11-devel (git-390196e) I get lightning artifacts with r600g on a couple of games from frozenbyte.com, most notably when using the flashlight in shadowgrounds. Here's a apitrace capture: http://static.hackmii.com/dhewg/shadowgrounds.apitrace.xz When replaying it via glretrace there're some weird window resizes, but the issue is visible when it doesn't crash :) The issue does not exist with swrast. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #6 from gottfried.hai...@gmail.com 2011-05-17 11:29:02 PDT --- Disabling page flip indeed fixes the flickering in both games. I am attaching both files you requested (from my boot with page flip disabled). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #7 from gottfried.hai...@gmail.com 2011-05-17 11:30:18 PDT --- Created an attachment (id=46836) -- (https://bugs.freedesktop.org/attachment.cgi?id=46836) dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #8 from gottfried.hai...@gmail.com 2011-05-17 11:31:08 PDT --- Created an attachment (id=46837) -- (https://bugs.freedesktop.org/attachment.cgi?id=46837) xorg.log from booting current xorg-edgers ppa with page flip disabled -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: add overlays as first class KMS objects
Hi Daniel, On Friday 13 May 2011 18:16:30 Daniel Vetter wrote: Hi Jesse, Discussion here in Budapest with v4l and embedded graphics folks was extremely fruitful. A few quick things to take away - I'll try to dig through all the stuff I've learned more in-depth later (probably in a blog post or two): - embedded graphics is insane. The output routing/blending/whatever currently shipping hw can do is crazy and kms as-is is nowhere near up to snuff to support this. We've discussed omap4 and a ti chip targeted at video surveillance as use cases. I'll post block diagrams and explanations some when later. - we should immediately stop to call anything an overlay. It's a confusing concept that has a different meaning in every subsystem and for every hw manufacturer. More sensible names are dma fifo engines for things that slurp in planes and make them available to the display subsystem. Blend engines for blocks that take multiple input pipes and overlay/underlay/blend them together. Display subsytem/controller for the aggregate thing including encoders/resizers/outputs and especially the crazy routing network that connects everything. Most of the discussion centered around clearing up the confusion and reaching a mutual understanding between desktop graphics, embedded graphics and v4l people. Two rough ideas emerged though: 1) Splitting the crtc object into two objects: crtc with associated output mode (pixel clock, encoders/connectors) and dma engines (possibly multiple) that feed it. omap 4 has essentially just 4 dma engines that can be freely assigned to the available outputs, so a distinction between normal crtcs and overlay engines just does not make sense. There's the major open question of where to put the various attributes to set up the output pipeline. Also some of these attributes might need to be changed atomicly together with pageflips on a bunch of dma engines all associated with the same crtc on the next vsync, e.g. output position of an overlaid video buffer. I like that idea. Setting attributes atomically will likely be one of the biggest challenge. V4L2 shares the same need, but we haven't had time to address it yet. 2) The above should be good enough to support halfway sane chips like omap4. But hw with more insane routing capabilities that can also use v4l devices as sources (even video input connectors) media controller might be a good fit. Media controller is designed to expose multimedia pipe routing across different subsystem. But the first version, still marked experimental, only got merged in .39. We discussed a few ideas as how to splice media controller into kms but nothing clear emerged. So a possible kms integration with media controller is rather far away. You're probably right, but far away doesn't mean never. Especially when one of the media controller developers is interested in the project and could spend time on it :-) I've started working on a prototype implementation that would use the media controller API to report the CRTCs, encoders and connectors topology to userspace. The learning curve is pretty steep as I'm not familiar with the DRM and KMS code, but the code base turned out to be much easier to dive in than it seemed a couple of years ago. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #9 from Alex Deucher ag...@yahoo.com 2011-05-17 11:59:48 PDT --- This is probably a duplicate of bug 35452. Does the xserver patch there help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #10 from gottfried.hai...@gmail.com 2011-05-17 12:58:33 PDT --- I compiled xserver-xorg from xorg-edgers ppa with the patch applied, and unless there is more to it than replacing libdri2.so with the newly compiled version this does _not_ fix the issue for me. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #11 from Alex Deucher ag...@yahoo.com 2011-05-17 13:05:09 PDT --- You might try these patches as well: http://lists.freedesktop.org/archives/xorg-devel/2011-May/021907.html http://lists.freedesktop.org/archives/xorg-devel/2011-May/021909.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37289] [600g] Texture corruption and flickering in OpenArena on X120e (E-350)
https://bugs.freedesktop.org/show_bug.cgi?id=37289 --- Comment #13 from gottfried.hai...@gmail.com 2011-05-17 13:35:25 PDT --- http://www.youtube.com/watch?v=rywJs08LoKk -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-intel-next
I've pushed four more patches to this branch for your merging pleasure. * Disabling FBC on Ironlake to enable RC6 instead Two patches for this are included. The following changes since commit 645c62a5e95a5f9a8e0d0627446bbda4ee042024: drm/i915: split PCH clock gating init (2011-05-13 18:12:53 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git drm-intel-next Feng, Boqun (2): drm/i915: fix user irq miss in BSD ring on g4x drm/i915: clean up unused ring_get_irq/ring_put_irq functions Jesse Barnes (2): drm/i915: add fbc enable flag, but disable by default drm/i915: enable rc6 by default drivers/gpu/drm/i915/i915_debugfs.c |3 ++ drivers/gpu/drm/i915/i915_drv.c |7 +++- drivers/gpu/drm/i915/i915_drv.h |2 + drivers/gpu/drm/i915/intel_display.c|5 +++ drivers/gpu/drm/i915/intel_ringbuffer.c | 50 ++ 5 files changed, 38 insertions(+), 29 deletions(-) -- keith.pack...@intel.com pgpnC4F7uzAzK.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] Standardize YUV support in the fbdev API
Hi everybody,
I need to implement support for a YUV frame buffer in an fbdev driver. As the
fbdev API doesn't support this out of the box, I've spent a couple of days
reading fbdev (and KMS) code and thinking about how we could cleanly add YUV
support to the API. I'd like to share my findings and thoughts, and hopefully
receive some comments back.
The terms 'format', 'pixel format', 'frame buffer format' and 'data format'
will be used interchangeably in this e-mail. They all refer to the way pixels
are stored in memory, including both the representation of a pixel as integer
values and the layout of those integer values in memory.
History and current situation
-
The fbdev API predates YUV frame buffers. In those old days developers only
cared (and probably thought) about RGB frame buffers, and they developed an
API that could express all kind of weird RGB layout in memory (such as R-
GGG- for instance, I can't imagine hardware implementing that).
This resulted in individual bit field description for the red, green, blue and
alpha components:
struct fb_bitfield {
__u32 offset; /* beginning of bitfield*/
__u32 length; /* length of bitfield */
__u32 msb_right; /* != 0 : Most significant bit is */
/* right */
};
Grayscale formats were pretty common, so a grayscale field tells color formats
(grayscale == 0) from grayscale formats (grayscale != 0).
People already realized that hardware developers were crazily inventive (the
word to remember here is crazily), and that non-standard formats would be
needed at some point. The fb_var_screeninfo ended up containing the following
format-related fields.
struct fb_var_screeninfo {
...
__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 */
...
};
Two bits have been specified for the nonstd field:
#define FB_NONSTD_HAM 1 /* Hold-And-Modify (HAM)*/
#define FB_NONSTD_REV_PIX_IN_B 2 /* order of pixels in each byte is reversed
*/
The FB_NONSTD_HAM bit is used by the video/amifb.c driver only to enable HAM
mode[1]. I very much doubt that any new hardware will implement HAM mode (and
I certainly hope none will).
The FB_NONSTD_REV_PIX_IN_B is used in video/fb_draw.h by the generic bitblit,
fillrect and copy area implementations, not directly by drivers.
A couple of drivers hardcode the nonstd field to 1 for some reason. Those are
video/arcfb.c (1bpp gray display), video/hecubafb.c (1bpp gray display) and
video/metronomefb.c (8bpp gray display).
The following drivers use nonstd for various other (and sometimes weird)
purposes:
video/arkfb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/fsl-diu-fb.c
Set var-nonstd bits into var-sync (why?)
video/pxafb.c
Encode frame buffer xpos and ypos in the nonstd field
video/s3fb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/vga16fb.c
When panning in non-8bpp, non-text mode, decrement xoffset
Do some other weird stuff when not 0
video/i810/i810_main.c
Select direct color mode when set to 1 (truecolor otherwise)
Fast forward a couple of years, hardware provides support for YUV frame
buffers. Several drivers had to provide YUV format selection to applications,
without any standard API to do so. All of them used the nonstd field for that
purpose:
media/video/ivtv/
Enable YUV mode when set to 1
video/pxafb.c
Encode pixel format in the nonstd field
video/sh_mobile_lcdfb.c
If bpp == 12 and nonstd != 0, enable NV12 mode
If bpp == 16 or bpp == 24, ?
video/omap/omapfb_main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422, YUV420 or YUY422)
video/omap2/omapfb/omapfb-main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422 or YUY422)
Those drivers use the nonstd field in different, incompatible ways.
Other related APIs
--
Beside the fbdev API, two other kernel/userspace APIs deal with video-related
modes and formats.
- Kernel Mode Setting (KMS)
The KMS API is similar in purpose to XRandR. Its main purpose is to provide a
kernel API to configure output video modes. As such, it doesn't care about
frame buffer formats, as they are irrelevant at the CRTC output.
In addition to handling
Re: [RFC] Standardize YUV support in the fbdev API
On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: I need to implement support for a YUV frame buffer in an fbdev driver. As the fbdev API doesn't support this out of the box, I've spent a couple of days reading fbdev (and KMS) code and thinking about how we could cleanly add YUV support to the API. I'd like to share my findings and thoughts, and hopefully receive some comments back. The terms 'format', 'pixel format', 'frame buffer format' and 'data format' will be used interchangeably in this e-mail. They all refer to the way pixels are stored in memory, including both the representation of a pixel as integer values and the layout of those integer values in memory. This is a great proposal. It was about time! The third solution has my preference. Comments and feedback will be appreciated. I will then work on a proof of concept and submit patches. I also would prefer the third solution. I don't think there's much difference from the user-space point of view, and a new ioctl would be cleaner. Also the v4l2 fourcc's should do. Cheers. -- Felipe Contreras ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-intel-next
On Tue, 17 May 2011 15:00:01 -0700, Keith Packard kei...@keithp.com wrote: I've pushed four more patches to this branch for your merging pleasure. And, one more which fixes non-eDP displays on Ironlake systems after the Ivybridge merge. Sorry for not catching that in our testing... The following changes since commit a51f7a66fb5e4af5ec4286baef940d06594b59d2: drm/i915: enable rc6 by default (2011-05-17 14:33:38 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git drm-intel-next Keith Packard (1): drm/i915: FDI link training broken on Ironlake by Ivybridge integration drivers/gpu/drm/i915/intel_display.c |8 1 files changed, 4 insertions(+), 4 deletions(-) -- keith.pack...@intel.com pgplK9iXoyOxv.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Standardize YUV support in the fbdev API
On Wed, 2011-05-18 at 00:07 +0200, Laurent Pinchart wrote:
Hi everybody,
I need to implement support for a YUV frame buffer in an fbdev driver. As the
fbdev API doesn't support this out of the box, I've spent a couple of days
reading fbdev (and KMS) code and thinking about how we could cleanly add YUV
support to the API. I'd like to share my findings and thoughts, and hopefully
receive some comments back.
I haven't looked at anything below, but I'll mention that the ivtv
driver presents an fbdev interface for the YUV output stream of the
CX23415.
It may be worth a look and asking Hans what are the short-comings.
-Andy
The terms 'format', 'pixel format', 'frame buffer format' and 'data format'
will be used interchangeably in this e-mail. They all refer to the way pixels
are stored in memory, including both the representation of a pixel as integer
values and the layout of those integer values in memory.
History and current situation
-
The fbdev API predates YUV frame buffers. In those old days developers only
cared (and probably thought) about RGB frame buffers, and they developed an
API that could express all kind of weird RGB layout in memory (such as R-
GGG- for instance, I can't imagine hardware implementing that).
This resulted in individual bit field description for the red, green, blue
and
alpha components:
struct fb_bitfield {
__u32 offset; /* beginning of bitfield*/
__u32 length; /* length of bitfield */
__u32 msb_right; /* != 0 : Most significant bit is */
/* right */
};
Grayscale formats were pretty common, so a grayscale field tells color
formats
(grayscale == 0) from grayscale formats (grayscale != 0).
People already realized that hardware developers were crazily inventive (the
word to remember here is crazily), and that non-standard formats would be
needed at some point. The fb_var_screeninfo ended up containing the following
format-related fields.
struct fb_var_screeninfo {
...
__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 */
...
};
Two bits have been specified for the nonstd field:
#define FB_NONSTD_HAM 1 /* Hold-And-Modify (HAM)*/
#define FB_NONSTD_REV_PIX_IN_B 2 /* order of pixels in each byte is
reversed
*/
The FB_NONSTD_HAM bit is used by the video/amifb.c driver only to enable HAM
mode[1]. I very much doubt that any new hardware will implement HAM mode (and
I certainly hope none will).
The FB_NONSTD_REV_PIX_IN_B is used in video/fb_draw.h by the generic bitblit,
fillrect and copy area implementations, not directly by drivers.
A couple of drivers hardcode the nonstd field to 1 for some reason. Those are
video/arcfb.c (1bpp gray display), video/hecubafb.c (1bpp gray display) and
video/metronomefb.c (8bpp gray display).
The following drivers use nonstd for various other (and sometimes weird)
purposes:
video/arkfb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/fsl-diu-fb.c
Set var-nonstd bits into var-sync (why?)
video/pxafb.c
Encode frame buffer xpos and ypos in the nonstd field
video/s3fb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/vga16fb.c
When panning in non-8bpp, non-text mode, decrement xoffset
Do some other weird stuff when not 0
video/i810/i810_main.c
Select direct color mode when set to 1 (truecolor otherwise)
Fast forward a couple of years, hardware provides support for YUV frame
buffers. Several drivers had to provide YUV format selection to applications,
without any standard API to do so. All of them used the nonstd field for that
purpose:
media/video/ivtv/
Enable YUV mode when set to 1
video/pxafb.c
Encode pixel format in the nonstd field
video/sh_mobile_lcdfb.c
If bpp == 12 and nonstd != 0, enable NV12 mode
If bpp == 16 or bpp == 24, ?
video/omap/omapfb_main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422, YUV420 or YUY422)
video/omap2/omapfb/omapfb-main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422 or YUY422)
Those drivers use the nonstd field in different, incompatible ways.
Other related APIs
Re: [RFC] Standardize YUV support in the fbdev API
Oops. Nevermind, you already have looked at what ivtvfb does. -Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36172] xf86-video-ati-git causes Gnome 3 crash (Radeon HD5770 - r800)
https://bugs.freedesktop.org/show_bug.cgi?id=36172 Jonathan Serafini seraf...@archlinux.us changed: What|Removed |Added CC||seraf...@archlinux.us --- Comment #9 from Jonathan Serafini seraf...@archlinux.us 2011-05-17 18:28:10 PDT --- Hi Michel, Good first troubleshooting steps. I too experienced the exact same errors (radeonSetSpanFunctions: bad format:) as soon as I would touch any of the widgets on the panel (ex.: volume control). I too run archlinux and was running most of the same -git ati/dri/mesa stack as Sascha. Apparently, downgrading libdrm-git-20110512-1-x86_64.pkg.tar.xz to libdrm-2.4.25-1-x86_64.pkg.tar.xz seems to have done the trick. Should you need more info, please let me know. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36753] Some textures now rendered as completely black after register allocator rewrite.
https://bugs.freedesktop.org/show_bug.cgi?id=36753 Tom Stellard tstel...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Tom Stellard tstel...@gmail.com 2011-05-17 19:18:57 PDT --- Fixed in git by commit 217cd216eac65983004ca77a9e49dbfad1b720b6. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36812] GPU lockup in Team Fortress 2
https://bugs.freedesktop.org/show_bug.cgi?id=36812 --- Comment #4 from Tom Stellard tstel...@gmail.com 2011-05-17 21:21:18 PDT --- If you run with MESA_GLSL=nopt, does it still crash? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
