Nightwulf|work: hi all
Oleg_: With the radeonhd driver, 1080p video will play fine?
Oleg_: I am already running this driver.
MostAwesomeDude: Oleg_: There's no magic involved. If it works, it works.
girrr: I just installed a HD4850 and it seems to work but the colors are over saturated. Is this a known problem and/or is there any workarounds?
Zajec: didn't hear about this
Zajec: do you use version from git?
girrr: yes
girrr: the version is from last week or so but I couldn't get the current one to build
Zajec: uh, then you probably need for repo
Zajec: uh, then you probably need for response from some developer rather than me :)
girrr: ok, thanks anyway ;)
Zajec: did you try other output? for example if you use VGA (D-SUB) what about DVI/HDMI?
Zajec: this info may be interesting for developers
girrr: I have two DVI -> DSUB adapters that is connected to two dell flat panels
girrr: I can try to exchange one of the cables to DVI with another monitor
Zajec: i think would be nice to try that
Zajec: also you may try to post mail on mailinglist with problem+this test result
Zajec: (if you won't get answer here soon)
girrr: ok
girrr: it seems to be correct with another monitor through DVI
Zajec: probably you discovered new bug ;)
Zajec: i think you should post this on mailinglist
Zajec: it's hard to hope that person responsible for this pice of code will be there today
girrr: ok, thanks
libvde: girrr: it's ok with another monitor?
libvde: are these the same dell monitors?
girrr: libvde, it worked with another type of monitor through DVI
libvde: girrr: on the same connector?
girrr: libvde, yes
libvde: same resolution?
girrr: libdve, yes
libvde: same dotclock?
girrr: libvde, how do I tell?
libvde: check the log, it's always the first number of a modeline after the modename string
girrr: libvde, I did hotplug the monitor in and out, does it end up in the Xorg.log anyways?
libvde: girrr: ah, then it is the exact same mode
libvde: girrr: in this case, you can only blame the monitor
libvde: girrr: go into the osd of the overly saturated monitor, and adjust its colour temperature
girrr: libvde, ok, but it has worked with my older hd3850 and before that a 9800pro
girrr: libvde, and I had a similar problem with the 9800 but agd5f fixed it for me...
libvde: girrr: ok, what was the fix?
girrr: libdve, it was a workaround in the ati driver
girrr: Option "DefaultTVDACAdj" "true"
girrr: however that card was a integrated laptop card
girrr: but both monitors worked fine with the hd3850 yesterday
libvde: so the current card is a desktop variant?
girrr: libvde, yes it's a pci express 16 as the former hd3850
libvde: two dvi-i connectors?
girrr: yes both for the hd4850 and the hd3850
girrr: the two dell fp1905 is connected with dvi -> dsub converters
libvde: ok, move the overly saturated monitor to the other dvi-i connector
libvde: does this fix things?
girrr: both of the monitors connected with dvi -> dsub connectors are overly saturated
girrr: the third monitor I tried through dvi wasn't overly saturated
libvde: hrm
girrr: unfortunaly the monitors aren't that easily moved so I can't try them with dvi since the cables are to short
egbert: girrr: so it happens when you use the analog vga input.
egbert: s/\./?/
Zajec: could someone help me understanding RHDRRValidateScaledToMode ?
Zajec: currently this function is called only for validating native mode... is this going to change in future?
girrr: egbert, yes
libv: Zajec: egbert put a lot of thought into scaling and the infrastructure for it
libv: Zajec: in the end he came up with a solution he's rather happy with
libv: Zajec: chances are, that this is rather futureproof
Zajec: libv: ok, thanks
egbert: Zajec: we set the native mode and scale to other resolutions. we could do for other outputs as well.
egbert: if the internal scaling proves to be better than lcd monitor scaling.
egbert: girrr: can you send me a log? (verbose 7).
Zajec: egbert: i didn't dig into whole scaling
Zajec: egbert: what do you think about adding new "Bool Strict" argument to rhdMonitorValid?
Zajec: egbert: in case of native mode reported by PANEL we could pass "FALSE"
Zajec: (do you remember my problem with M82?)
Zajec: mode reported by panel is rejected because this strict check
egbert: hrm, ok, was that the one where validation was too strict?
girrr: egbert, Can I pass logverbose to startx or do I have to execute X manually?
libv: Zajec: the sony thing, which hit the too little blanking but not reduced blanking check
Zajec: egbert: right
Zajec: libv: i belive we have the same on mind
egbert: libv: we should relax the validation for the device where the mode originates from.
Zajec: libv: it's that sony panel
girrr: egbert, never mind, brb
egbert: if we use such a mode for anything else we want to check for strict cvt compliance.
egbert: as it was done when this code was originally implemented.
libv: egbert: how would you go about something like this?
libv: egbert: relax the check on the native resolution, and then, when the same mode from the modelist is exactly the same as native, allow it before any other checks?
Zajec: egbert: libv: http://files.zajec.net/less.strict.check.for.native.diff
egbert: libv: yes, you could compare it against the natove mode of that montior.
egbert: libv: you have it available in this function.
egbert: so when it matches the native mode: relax; else check against cvt.
girrr: egbert: sorry for the delay, here is the log http://picard.hgo.se/~kristian/Xorg.0.log
libv: well, move this check in front of just about anything
libv: because most of the sanity checks and such should've already been done on the native resolution
libv: not only the blanking check
egbert: libv: me? i thought you are going to do that :p
Zajec: :D
libv: egbert: not before CS works nicely :p
egbert: Zajec: your turn :p
Zajec: guys, please ;)
libv: Zajec: you have a bug open on this thing right?
Zajec: nope
libv: Zajec: and, for now, it is working for you with your own hacked version?
libv: well, open one, we'll get to it in the next few weeks :)
Zajec: libv: yeah, i have to use hacked version and then it works fine
Zajec: for last 2 weeks :) didn't burn my PANEL nor cat :)
Zajec: uhm. hoped it can be fixed in few minutes
Zajec: which bugzilla should I use? freedesktop? opensuse?
egbert: Zajec: freedesktop
egbert: girrr: can you use rhd_conntest to dump me your BIOS?
girrr: egbert: sure, one sec
girrr: egbert: http://picard.hgo.se/~kristian/posted.vga.rom
egbert: girrr: thanks!
girrr: egbert: np, thanks for taking an intrest in this
egbert: girrr: could you please do something else? when you have text mode on a monitor connected thru vga can you do a: rhd_dump
thomastp: Hi. I just got a new samsung monitor that can do 1920x1080
thomastp: xrandr -q shows 1400x1050 as the maximum resolution though
thomastp: can I do anything about that ?
Zajec: egbert: libv: https://bugs.freedesktop.org/show_bug.cgi?id=17386
girrr: egbert: It doesn't seem to generate any file or so
girrr: egbert: It just states: Unknown device: 0x1002:0x9442 (07:00.00)
egbert: girrr: ok, it doesn't know you chipset yet.
girrr: egbert: ok, can we get around that somehow?
egbert: girrr: i'm checking...
thomastp: hm, adding modelines from the internet allowed me to run at 1920x1200
libv: Zajec: thanks :)
thomastp: now I want to set up my second screen for spanning desktops, the second screen can do 1024x768, but it can be rotated
thomastp: when doing xrandr --output VGA_1 --rotate left, xrandr says it cannot use rotation left reflection none
thomastp: any idea why that would be ?
egbert: thomastp: no rotation yet.
thomastp: egbert: ah, this is a driver thing ? it's just not implemented ?
egbert: thomastp: you need some driver support for it.
thomastp: egbert: ok - and the radeonhd driver just doesn't have it I assume ? I assume it's not high priority ?
egbert: thomastp: not atm. it shouldn't be too hard to add.
thomastp: egbert: ok, thanks. I'll just use it non-rotated for now.
egbert: girrr: yes, you can add the pciid to rhd_dump.
egbert: i think rhd_conntest is fine. take it from there.
girrr: egbert: ok, i'll try that
egbert: girrr: ok.
egbert: girrr: there is some other test you could make...
thomastp: egbert: what sort of work is needed to be able to add rotation ? isn't it just a matter of making the driver do a linear transformation on the x and y coords ?
thomastp: basically swap and invert ?
girrr: egbert: rhd_dump: 0x7EF4: 0x00221F02
egbert: thomastp: this code is in the common level already. just some hooks need to be set.
egbert: basically one would look at another driver and check.
egbert: ... how it's done.
egbert: girrr: thx!
thomastp: egbert: oh, so it really sounds like a 50 line patch at most ? maybe I should give it a try then
egbert: thomastp: yes, please do!
egbert: the little catch is that it might not work well with all accel modes.
thomastp: egbert: ok, I'll give it a shot. what driver should I look at to see it, and what functions am I looking for ?
egbert: intel for instance.
thomastp: ok, thanks
hansk: Hi guys, I hope someone here can help me out a bit. I am suspecting that something is wrong with the bios of my card and that the driver does not manage to work around it.
hansk: Basically the problem is that I only get output on one screen even though it says the other is activated and that the correct mode is set. And of course the menus are all on that other monitor so I'm not even able to get a shell while in X
hansk: Now I have tried everything I can find of hints and tips on the net and in the many man pages, but the only thing that really makes a difference is the "NoRandr" option. If I specify that then I get both displays powered on, but unfortunately I only get clones.
hansk: The chip is a rv620, and I am running a git snapshot about 5 hours old.
egbert: hansk: we have more of these reports. i still don't know what it is. i cannot reproduce it here.
egbert: girrr: i've just pushed a fix for your problem. please test.
hansk: one thing that I am suspecting has something to do with this is the output from rhd_conntest: "HotPlug: RHD_HPD_0 RHD_HPD_1 RHD_HPD_2" <- it lists 3 when there should be 2, no?
hansk: egbert: If you want me to, i could do some tests for you if you have any. I have some knowledge in troubleshooting, but after 3 days I am running out of ideas :)
girrr: egbert: i'll try the latest git, sorry for the delay
egbert: hansk: let me think if i can come up with something. are you going to stick around here for a while?
girrr: egbert: It still seems to be over saturated
hansk: egbert: I'll be here for 1.5 hours more today (at work). Then I'll be back on wed. Just leave me a message and I'll reply as soon as I see it.
hansk: ie, I work here 3 days a week. So that is when I can do the testing.
egbert: hansk: ok.
egbert: girrr: can you do the same dump inside X?
girrr: girrr: i'll try, one sec
girrr: egbert: you'll have to escuse my long delays, I've been running around in some work arends...
girrr: egbert: 0x7EF4: 0x00001F02
egbert: girrr: this is still the wrong value. are you sure you installed the new driver correctly?
girrr: egbert: it should be
girrr: egbert: I tried to pull the latest git again but it says rhd_dump.c needs update and couldn't be merged
girrr: egbert: maybe I was a little to fast and didn't read properly before recompling...
egbert: this is because i've added the pci ids.
girrr: egbert: now I did pull som more changes
girrr: egbert: I'll try again
girrr: egbert: now it works
girrr: egbert: thanks very much!
girrr: egbert: No the value has changed, 0x00221F02
egbert: girrr: ok. so your problem's fixed now?
girrr: egbert: it seems so ;)
girrr: egbert: Thanks again..
awosy: where can i find a stable version of the radeonhd?
awosy: on the wiki page there is no link to a tar file...
awosy: ok nevermind just found a link
m-c: Are there directions for keeping up with the latest RadeonHD drivers written online, specifically for OpenSUSE?
m-c: There was a nice write up on phoronix explaining the procedure within Ubuntu, but I have not found a nice guide like that for SUSE
m-c: I suspect I need to update my xserver version, at least, for the latest radeonhd drivers...