Nightwulf|work: hi all
Zajec: what is difference between transmitter and encoder?
Zajec: http://wiki.x.org/wiki/Development/Documentation/HowVideoCardsWork uses "transmitter" for LVDS and TMDS and "encoder" for TV... is that right?
Zajec: oh, and in radeonhd source file I see comment:
Zajec: * Deals with the Shared LVDS/TMDS encoder.
Zajec: emmes: i've to spent to time to understand all these digial blocks... now can big into backlight problem you should remember from ML :)
Zajec: er "had to" i meant
emmes: :)
emmes: transmitter and encoder are just two parts that typically are combined, but on newer ATI cards are separate entities
Zajec: yeah, already have quite clear view on that, thanks to bridgman :)
Zajec: emmes: do you have idea what may be inverted backlight?
Zajec: BlonPol = (tmp >> 26) & 0x1;
Zajec: BlonPol ? "invert" : "non-invert"
emmes: no freaking clue. I think Egbert did that code.
Zajec: is Egbert contactable? :)
emmes: theoretically yes :-P
emmes: eich@suse.de
Zajec: i love theory ;)
Zajec: can I somehow easy tell radeonhd to use UNIPHY to controll my PANEL?
Zajec: emmes: do you still have a moment today to commit my doc patch?
emmes: the encoder for the panel is hardwired.
Zajec: ouch... that's bad
Zajec: wish to test that
emmes: afaik
emmes: patch looks good, but I doubt that this should be in rhd_dig.c...
Zajec: where then? :) rhd_dig.c looked fine
Zajec: do you think there is any PANEL controlled by UNIPHY?
emmes: hm, right. maybe it's the best place.
emmes: at some point of time we probably want a "developer's documentation" - either a README.code or a wiki page...
emmes: panel with uniphy? I have *no* idea...
emmes: rs880, maybe?
emmes: M92/M94/M96 maybe?
emmes: patch applied.
bridgman: at some point we're all expecting dp to replace lvds for panels
bridgman: but like so many things it's not happening as fast as we would like
emmes: i imagine...
Zajec: emmes: thanks for applying
Zajec: emmes: doc for developers would be great
Zajec: there are too many too often cases i don't understand sth
Zajec: I just think about removing LVDS backlight code from rhd_dig.c... even if we will find PANEL controlled by UNIPHY/DP at some time, we will need probably different code for backlight controll
emmes: you should probably ask on the list first. maybe somebody needs it.
Zajec: oki
Zajec: emmes: applied localy? ;)
Zajec: (again)? ;)
emmes: yeah, there might be some other stuff i have to commit.
emmes: not sure yet.
emmes: also, i had some success in understanding PowerPlayInfo V4.1 (as on the newer cards).
emmes: -> blog ;)
Zajec: emmes: do you mean AtomBIOS table?
Zajec: reading
emmes: yep
Zajec: wow, great
Zajec: what do you mean by RE?
Zajec: how did you get that?
Zajec: i hope no by looking at HEXs?
emmes: well - looking at hex dumps, until something hit me :-P
Zajec: you're crazy :P
emmes: ...sometimes... ;)
Zajec: there is such a mess in code... argh
Zajec: great function name: LVDSTransmitterPropertyControl
Zajec: now guess is this LVDS transmissed by UNIPHY or LVTMA...
Zajec: UNIPHY uses: LVDSTransmitterPropertyControl
Zajec: LVTMA uses: LVDSPropertyControl
emmes: uhg
emmes: ugh
Zajec: Err. moment, what for is rhd_dig.c?
Zajec: nobody knows anymore :p
emmes: it's only for the newer DIG blocks. Apparently there are 3, KLDSKP_LVTMA, UNIPHYA, and UNIPHYB
emmes: DIG is the newest of the system.
emmes: and thinking of that, the docu patch is definitely at the wrong place.
Zajec: ahh, so it's for UNIPHY generally?
emmes: yes
Zajec: emmes: yes!
Zajec: emmes: please, don't apply that, can you still cancel it?
emmes: haven't pushed yet :)
emmes: I would suggest we start a new README.code
Zajec: probably right thinkg to do
emmes: or better README.coding
Zajec: i really prefer "UNIPHY" ofer "DIG" :/
Zajec: but what the hell "LVTMA" is doing in rhd_dig.c
Zajec: i had full rights to be confused :)
emmes: this is a different LVTMA...
Zajec: I understand UNIPHY can transmit LVDS... but it isn't called LVTMA anymore, is it?
emmes: ...
Zajec: stupid question? ;)
Zajec: brb
Zajec: emmes: little help needed... what does it mean:
Zajec: (II) RADEONHD(0): Connector[1] {RHD_CONNECTOR_PANEL, "LVDS LCD1", RHD_DDC_NONE, RHD_HPD_NONE, { RHD_OUTPUT_KLDSKP_LVTMA, RHD_OUTPUT_NONE } }
Zajec: (II) RADEONHD(0): Connector[2] {RHD_CONNECTOR_DVI_SINGLE, "HDMI_TYPE_A DFP1", RHD_DDC_2, RHD_HPD_0, { RHD_OUTPUT_UNIPHYA, RHD_OUTPUT_NONE } }
Zajec: do I have two UNIPHYSes?
Zajec: I guess so... (--) RADEONHD(0): Attaching Output UNIPHY_KLDSKP_LVTMA to Connector PANEL
emmes: rather 3
Zajec: hm?
Zajec: three? i have only two digital connectors
Zajec: anyway, good to know my PANEL is controlled by UNIPHY :)
Zajec: (II) RADEONHD(0): Connector[0] {RHD_CONNECTOR_VGA, "VGA CRT1", RHD_DDC_0, RHD_HPD_NONE, { RHD_OUTPUT_DACA, RHD_OUTPUT_NONE } }
emmes: yes, but 3 encoders :-P or transmitters? outputs? ...
Zajec: encoers yes :) asked about UNIPHYSes :)
emmes: I have added a README.coding. Will push soon
Zajec: oh, nice :)
Zajec: emmes: i posted backlight control for my M82
Zajec: this is not fix for Vlad..'s problem
Zajec: emmes: if you're fine with my patch, i'll prepare sth for Vladimir
Zajec: to tes
ub_1: For some reason, my TV_SVIDEO on R500 stays disconnected... anybody had any luck with enabling svideo?
Zajec: radeonhd doesn't support S_VIDEO i think
ub_1: Zajec: I can see output in xrandr by using Option "UseAtomBIOS" "true".
ub_1: Zajec: Also (Option "TVMode" "PAL").
Zajec: well, maybe... really don't know
ub_1: OK...
Xeccos: "(EE) RADEONHD(0): Cannot allocate 0 bytes of memory for BIOS image" among other things, my /var/log/Xorg.0.log is at http://dpaste.com/60091 , radeon HD 3200
Xeccos: anyone got any ideas?
yangman: ub_1: the tv-out port shows up in xrandr, but isn't actually connected to anything in code
yangman: emmes: I wouldn't say the PowerPlayInfo tables for rv770 is bogus. I've looked at it, too, and it corresponds exactly to what Catalyst under windows reports as the accepted range
Zajec: yangman: please...
yangman: Zajec: ?
Zajec: 0088: U24 engineClock = 0x001400 (5120)
Zajec: 008b: U24 memoryClock = 0xf80000 (16252928)
Zajec: don't want to fire my gpu :P
yangman: are they all like that or just a few at the end?
Zajec: all :)
yangman: odd
Zajec: i think AtomDis doesn't read one more ATOM_POWERINDEX_INFO_V4 which is there
Zajec: reported that to emmes already
AStorm: yeah, here powerplay also prints some weird values
AStorm: power saving is crummy though on my M88
ub_1: yangman: Thanks, I'll try with radeon, s-video is kind of working there...
ub_1: ... for certain definition of "working", that is. ;)
Zajec: if I call rhdAllIdle(...)... how can I resume verything?
yangman: Zajec: IIRC, CRTCs need to be brought back up again
Zajec: in RHDEnterVT RHDRandrModeInit probably does it?
Zajec: RHDRandrModeInit calls rhdPtr->Crtc[0]->Blank(rhdPtr->Crtc[0], TRUE);
Zajec: so probably that's it
Zajec: hm, I can SetMemoryClock in any moment
Zajec: AtomBIOS idles everything for me
Zajec: even while using Xv
Zajec: i just see short CRTC blinking and that's it
yangman: yup. that's what I saw, too
insta: are there any issues with audio out via hdmi on the radeon 3200? (eg: 780G chipset)
insta: or should i use another driver instead of radeonhd?
kevin06: bonne nuit
T`: anyone familiar if VESA 2.0 supports windowing?
AStorm: T`, windowing as in addressing part of linear frame buffer as a new one?
AStorm: nopes
T`: AStorm, hi.. yes
T`: AStorm, as in.. just like VGA mode you can set the "display pointer" to some region in the Video memory
T`: i am wondering i can i do that in linear FB mode
T`: AStorm, i am reading the vbe2 spec, and i see function 05 might do this for me, but the spec is vague in terms of if it works in linear buffer mode or not
AStorm: tiled is usually better for such things
AStorm: but that's not VESA 2
T`: AStorm, i am not familiar with tiled.. i am trying to stick to vesa 2 mode because i have a multiboot kernel which is setting me up in a linear fb mode of a resolution i requested
T`: AStorm, so in linear fb you can't actually make a simple call to switch the underlying video memory pointer? I assume linux console in svga mode is doing this right?
T`: otherwise the redrawing when switching between consoles would be too slow
AStorm: no, the console is scrolling
Digital_Pioneer: Hi. I'm seeing this in my X output: (EE) RADEONHD(0): RHDHdmiInit: unknown HDMI output type
AStorm: the only trick it has is that some cards allow a vertically large framebuffer and panning it
Digital_Pioneer: What can I do about that?
AStorm: yes, vesafb is slow
AStorm: (that panning stuff is VESA 3, used by uvesafb)
T`: AStorm, oh ic.. is scroll a hardware accelerated function available via vesa2?
AStorm: (VESA 3 also supports circular framebuffer)
T`: i can look at vesa 3, but i read many hardware dont support it
AStorm: most does
AStorm: nvidia, ati, newer s3, unichrome do
AStorm: no, scrolling is not accelerated in vesa 2
AStorm: (that's why univbe was so popular back in the time)
T`: AStorm, i am still surprised how scrolling can be so fast on linux console.. i am trying to draw a image (which is loaded in memory) to the videofb.. and i can actually see the draw go by slowly.. at 100% cpu.. when i have to scroll.. i have to redraw the entire screen again which takes many seconds
T`: AStorm, just read up on univbe.. it seems like a great piece of software!
AStorm: you're doing something wrong
AStorm: like flushing the fb after each write
T`: AStorm, pm..
Digital_Pioneer: OK so I kinda get things working even though I still get that HDMI error in xorg.conf, but when I start kdm there are vertical strips of noise down both sides of the screen...
Digital_Pioneer: Any idea what might be causing that? Or do I have to fall back to fglrx/catalyst?
T`: Digital_Pioneer, are your screens rotated?
T`: Digital_Pioneer, https://bugs.freedesktop.org/show_bug.cgi?id=21963 <--- is this what you are seeing?
Digital_Pioneer: T`: Nope
T`: Digital_Pioneer, i have a HD3450 and it has 1 HDMI and 1 DVI.. i am using both ports for dual screen now
Digital_Pioneer: T`: I haven't gone any further than kdm...
T`: Digital_Pioneer, did u try the latest radeonhd 1.2.6 or git version?
Digital_Pioneer: I have an HD4850 and I'm using 1 monitor on HDMI.
Digital_Pioneer: Crap... My system just crashed...
Digital_Pioneer: (I'm chatting from another computer)
Digital_Pioneer: OK, no it didn't, but it just slaughtered all my SSH connections...
T`: weird
T`: Digital_Pioneer, which version of radeonhd are you using?
Digital_Pioneer: And I can't reconnect... Am I gonna have to walk all the way over there (like 10 ft) to check what version I have?.. :(
Digital_Pioneer: 1.2.5
Digital_Pioneer: Ahh, the system went offline. Stupid wifi.
Digital_Pioneer: begins building package for radeonhd-git
T`: Digital_Pioneer, try the latest git.. a lot of things didn't work for me on 1.2.5.. but now it works very well
T`: Digital_Pioneer, are you on ubuntu?
Digital_Pioneer: T`: Nope, Arch
Digital_Pioneer: Still have the vertical strips...
T`: Digital_Pioneer, https://help.ubuntu.com/community/RadeonHD
T`: Digital_Pioneer, may be better to file a bug with screenshots
Digital_Pioneer: T`: Well first I'll have to get the darn mouse/kbd working... :P
AStorm: doesn't AUR have a pkgbuild for that?
Digital_Pioneer: AStorm: Yeah, I just installed it.
Digital_Pioneer: I was offline there for a minute and didn't realize it, so yaourt didn't show the AUR results.
Digital_Pioneer: Ahh, yes... Start HAL. That helped.
Digital_Pioneer: So I finally got around to making a user account and logging in... And after logging in the strips disappear. But they are still present in KDM. I think KDM is using the wrong resolution somehow.
Digital_Pioneer: Which is not your bug, I suppose.
T`: Digital_Pioneer, hmm.. reminds me of something i had to do
T`: and actually i had to do that on my HDMI port
T`: lemme look up
T`: Digital_Pioneer, ok.. what was happening was X setup 1920x1200 as my resolution, but for some reason my gdm didn't think it was that resolution.. i fixed it by doing a xrandr and setting the resolution to 1920x1200
AStorm: ?