emmes: gusta1: mis-location: Option "LeftOf" is broken in the server. Fixed in git. You can use "RightOf" with the other monitor, though :P
emmes: FlyingSpaghetti: what do you mean with 'my career'?
gusta1: LeftOf broken lol, ok.. I'll use RightOf.
emmes: gusta1: I assume you have monitors with different widhts.
emmes: s/widhts/widths/
emmes: the implementation so far only worked with same widths for LeftOf and Above ;)
gusta1: yep
gusta1: oh
gusta1: well, I went berzerk on xrandr yesterday and then suddenly, the right screen was correctly aligned... but that was probably just a coincidence... I'll move to RightOf if it usually works better. it's not that it's more difficult for me ;)
gusta1: but sure, I have a hard time understanding that it is different code which runs LeftOf and RightOf... should be the exact same...?
gusta1: in fact, there should only need to be one function: RightOf, since LeftOf = LeftOf->RightOf, semantically.
emmes: gusta1: the relative offset has to come from the own monitor in LeftOf and Above. It comes from the other monitor in RightOf and Below.
emmes: Indeed, you don't strictly need LeftOf, RightOf is enough. Still, sometimes it's easier to understand, so you want to provide both.
gusta1: ok
gusta1: around my cursor on a certain "column" (maybe 8px wide) of my left monitor, I get a scrambled screen, but it "heals" itself when the mouse move away
gusta1: a column around 760px from the left side of the screen
gusta1: I think between 746-766
rmh3093: is there a gitweb site for the radeonhd driver?
gusta1: heh, what a question...
gusta1: you found the irc channel before freedesktop's gitweb :P
gusta1: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd;a=summary
libv: Dottout: still around?
Dottout: hey ;)
libv: egbert just dug up an option
Dottout: I was lookin right now at git log
Dottout: fix test for blabla?
libv: you had a conntest run yesterday, right?
Dottout: yes
libv: and the HPD said none
Dottout: yep
Dottout: Im compiling now
libv: Dottout: was this a digital monitor or are you using a vga adapter?
libv: Dottout: no change to fix your thing yet :)
Dottout: dvi adapter
libv: so don't worry too much about it
Dottout: ah ok
libv: so dvi directly
Dottout: yes
Dottout: dvi to dvi
libv: and TMDSA showed
libv: ok, here is what egbert figured out: HPD can also be inverted
libv: we've never come across it before
Dottout: lucky bastard ehe
libv: so can you plug in the cable, and verify that it is HPD_NONE
libv: and then unplug the cable, and then hopefully, magically, some hpd bit will be pulled up
libv: hopes it is just broken hardware, as otherwise he would have to do a spot of coding. Egbert also will not be in the clear then too .p
Dottout: well, if i unplug dvi cable it says Load Detection: RHD_OUTPUT_NONE
Dottout: with dvi cable plugged: Load Detection: RHD_OUTPUT_TMDSA
libv: and what about HPD?
Dottout: HotPlug: RHD_HPD_NONE
Dottout: both times
libv: ah, yes, hrm
libv: lucky us :p
Dottout: broken hw??
libv: well...
Dottout: btw, with cable plugged in I have DDC: RHD_DDC_1 instead of ddc_non
Dottout: this monitor is 2 weeks old..
libv: Dottout: how many dvi connectors do you have?
libv: on your card?
Dottout: just 1
Dottout: x1400
libv: ah, hrm, ah, right, laptop
Dottout: yes, fujitsu pi1536
libv: hrm... do you have a multimeter there?
kdekorte: hotplug on my T61p (VGA_1) seems to work right
Dottout: ehm..what the hell is a multimeter? :D
libv: kdekorte: right, but this is a very board specific issue here
kdekorte: just my 'Virtual Size' is not big enough to run both
libv: kdekorte: provide a virtual size yourself
libv: kdekorte: driver is happy up to 8192x8192
kdekorte: is there anyway, we could get away from the manual virtual size so I don't have to restart X
Dottout: ok wikipedia told me the answer
libv: kdekorte: currently, no
Dottout: no, I dont have one
libv: Dottout: hrm, because it would be fun to measure out the voltage on the HPD pin
Dottout: well, just for a try, can you please tell me ho to clone with git 3days ago driver?
agd5f: kdekorte: ttm
Dottout: Im used to svn\cvs
Dottout: git's a new world for me
agd5f: memory manager
libv: agd5f: ?
libv: agd5f: and this will suddenly fix everything?
libv: agd5f: or will it still not be general after 2.5years, like exa?
kdekorte: libv, would be be possible in the driver to set the virtual size to 8192x8192 if one is NOT specified in the xorg.conf file?
libv: kdekorte: nope
libv: Dottout: git-branch
libv: Dottout: then checkout -f
Dottout: what is sha-idish? sorry for newbie questions :\
Dottout: you mean something like commit 1235392fd32ef836c1e81a0dc8304b04c873a318?
libv: Dottout: just take the first 8 characters or something
libv: Dottout: you never need to provide the full sha-id, just enough so that it is unique :)
libv: therefor -ish
Dottout: git-branch boh 78b763f97ab62 ; git-checkout -f boh said Switched to branch "boh"
Dottout: nice ;)
agd5f: libv: it's being designed with that in mind, so it is a possible solution
libv: agd5f: sure, but it will not deliver right away
libv: and i'm not very optimistic about the time such things take to become fully mainstream, fully stable, and supported everywhere
libv: as i said, exa tries to solve this too
agd5f: libv: sure. these things take time
Dottout: libv: is not broken hw :D
Dottout: 3days ago branch works back again
libv: Dottout: RandR?
Dottout: randr what?
libv: Dottout: guess what, three days ago, our RandR didn't use the HPD pin yet :p
Dottout: I branch-ed git-branch boh 78b763f97ab62
Dottout: ah
Dottout: lemme check the right date
Dottout: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd;a=commit;h=78b763f97ab62cf8d504cc238bb4d59c5b9bf6fa
libv: Dottout: can you mail me at radeonhd@opensuse.org , explain the issue briefly, provide the full name of your laptop, provide the full rhd_conntest result with: 1) nothing connected. 2) DVI connected. 3) VGA connected through the DVI-VGA adapter
Dottout: ok sure
Dottout: Load Detection: RHD_OUTPUT_NONE
Dottout: HotPlug: RHD_HPD_NONE
Dottout: vga+dvi adapter
Dottout: can you please tell me again the mail address?
ndim: Dottout: radeonhd@opensuse.org
Dottout: (sorry, wrong output, it sas rhd_output_daca but again hpd_none, I forgot to switch monitor to analog )
libv: Dottout: its mentioned in the /topic btw
libv: Dottout: it is all on the wiki
Dottout: ok, mail sent with the 3 txt attached
gusta1: damn it... i found a modeline which worked yesterday, but new git some freaking how (or X is just weird) it seems to send a slightly different picture, because I seem to have to re-calibrate the monitor :/
gusta1: also, RightOf didn't help. it's as bad as LeftOf.. well. almost. the desktop icons are still hidden in between the monitors, but gnome acts slightly better.
gusta1: could be a broken version of the xserver
ndim: Meh. xfs dies with SIGABRT.
ndim: Why can't stuff just work=?
Zhenech: because it's Xorg? :)
plectrum2: emmes: I got xrandr from git and now have dual-head instead of both having this same offset
plectrum2: emmes: but... the second screen is not right, it has a green tint to it (through DVI!) and some stuff just does not render right (xterm OK but this xchat is bad on that screen)
plectrum2: emmes: oh wait!!!! it was a twm bug!!! I switched to fvwm as twm was not letting me use the second screen fully (one edge of the window would have to be on the first screen) and now it works!
gusta1: a stone-age remanence doesn't understand randr correctly? I'm surprised...
plectrum2: is happy about having a dual-head (feals like Zaphod)
emmes: plectrum2: cool bug :-P
emmes: ndim: you're still using xfs? how strange... :-P
ndim: emmes: LTSP
emmes: ndim: an acrynom i don't know yet...
ndim: Linux Terminal Server Project
ndim: X11 terminal booting over the network.
ndim: Using some server's XFS.
emmes: gusta1: if RightOf doesn't work either, you might want to check the output of xrandr, and verify that the offsets are reasonable.
emmes: ndim: in that case, it makes at least a bit of sense :P
gusta1: I haven't done that since my windows and gnome panels seem to be located correctly on my monitor
gusta1: but when I look at it, it looks bad
gusta1: it locates the right monitor at 1280+0 when the left monitor is 1024, hence the right one should start at 1024+0
gusta1: however, since PreferredMode is broken, I always boot with the left monitor in 1280x800 which might be why the right monitor is stuck at 1280+0
gusta1: but that _should_ be changed when the left monitors resolution changes, shouldn't it?
gusta1: when correcting it manually with xrandr it gets corrected (for now). buggily buggily bug
gusta1: lol firefox didn't like that change... damn it. everything works so freakingly bad. I think I'll swap my outputs so that the bigger monitor is the first. that'll probably fix everything.
emmes: gusta1: LeftOf and RightOf are evaluated at invocation time, and transformed into Pos values.
emmes: so they don't change dynamically.
emmes: this is actually something the user agents should do.
emmes: so you have to reposition it again after changing the mode.
gusta1: oh... yes..
gusta1: I was the user agent this time, and I did half my job.. of course... heh, perhaps I should've thought about that
emmes: that has been a... lets call it... design decision.
gusta1: no problem. I'd love for grandr not to completely SUCK, but since it does, I'm stuck with xrandr, and am thereby forced to "know everything"
emmes: rotfl
emmes: is it *that* bad?
emmes: i never looked into it.
plectrum: looks like twm is not to blame for my second screen silliness. KDE does it too and killing kwin and starting openbox didn't help but starting fvwm did.
gusta1: grandr segfaults whenever I select any of my monitors... I'd say it's pretty bad.
plectrum: now I have killed fvwm and started kwin again and all is well
emmes: plectrum: this is ... strange.
plectrum: emmes: yep, it looks like some sync problem but the monitors OSD says everything is fine
plectrum: emmes: I wonder why fvwm clears it up. Could it be because it opens a lot of new desktops?
emmes: if xrandr shows you that the monitors support other refresh rates for the same mode, could you please try some of them (if you're seeing some issues)? If they change the behavior, send a mail to the mailing list, probably MACRO_CONTROL is setup wrong again.
plectrum: emmes: yes this looks suspicious "1280x1024 60.0*+ 75.0 59.9"
plectrum: the 60 and 59.9 look funny
kdekorte: are their any docs on the randr 1.2 api anywhere.. I'm trying to update my grandr_applet program to know the outputs
emmes: plectrum: it's not unusual for monitors to report two different modes that are slightly different.
emmes: kdekorte: there's randrproto.txt in the proto/randr git.
plectrum: emmes: going from 60->75 doesn't change anything. Am I doing this right? `xrandr --output DVI-I_2/digital --refresh 75.0`
kdekorte: thanks... another question in the radeon driver outputs are named 'VGA-0' and in radeonhd they are named 'VGA_0' any chance of maing them the same
kdekorte: plectrum, is this an LCD panel? if so aren't those usually 60Hz only
plectrum: kdekorte: oh I didn't know that. Yes the recommended is 60Hz from the panel, but changing it from 60.0 to 59.9 also doesn't change what xrandr -q reports
plectrum: reports as using
plectrum2: emmes: restarted X and got the issue again. I can't successfully play with the refresh rates from the command line but krandrtray can. This however does not make the artefacts on the second screen go away.
emmes: kdekorte: I have no idea how the radeon driver is naming DVI-I connectors... so they probably won't be the same anyway, at least not at the beginning
emmes: plectrum2: I'd probably need a screenshot (with a digital camera, and for comparison with a screen dumper). best create a bug report for that.
kdekorte: emmes, well maybe there should be a standard on if the CTRC id should be separated with a - or a _ before the numeric id
emmes: kdekorte: there won't be
plectrum2: emmes: ok tomorrow I will bring a camera in and create a bug report
emmes: IMHO using names for meta information is broken anyways.
emmes: plectrum2: great
emmes: kdekorte: RandR 1.3 is supposed to include meta information in a standardized way
emmes: radeonhd so far is the only driver that implements this approximately (because nobody knows the details yet). xrandr -q --prop
kdekorte: emmes, ok sounds good
luke-jr: What *is* atombios?
agd5f: luke-jr: a set of scripts an tables stored in rom on newer radeon chips
agd5f: s/an/and/
luke-jr: why does it seem to be a big deal?
agd5f: luke-jr: ? it can do a lot of stuff
luke-jr: scripts and tables?
libv: "scripts"
libv: luke-jr: it's "scripts" in the rom
libv: so no changing them
libv: and they are also not written like scripts, they are written like any other bios
libv: made to pass some test cases, but never to be looked at again
libv: it is also very limited
libv: no pll calculation
libv: no palette
libv: no hw cursor
libv: no hpd handling
libv: no load detection for tmds
libv: and when they bugger up, you're SOL.
luke-jr: O.o
libv: plus, you're completely tied to the interface as well. if the driver model is too different from the abstraction in there, you're SOL again
libv: it's sool, isn't it
agd5f: luke-jr: it's what the bios, the windows driver and fglrx use for mode setting, card init, power management, etc.
luke-jr: but didn't all that work without it? O.o
libv: agd5f: next windows version, you're not supposed to use an R5xx or R6xx any more
agd5f: luke-jr: you can program it directly or via the scripts
libv: agd5f: and fglrx has dropped support for r100 already, maybe even r200 too
agd5f: libv: fglrx never supported r100
libv: so they dropped r200 then?
agd5f: and r200 was dropped long ago. neither has atom bios
luke-jr: so what advantage do the scripts have if RadeonHD already did it directly?
libv: sure, but it does explain the mindset of heavily atombios function table dependent stuff
mjg59: They know about new hardware
libv: mjg59: like what?
agd5f: luke-jr: they have asic specific quirks in some cases and support for initializing other chips attached via i2c or gpio in certain oem designs
mjg59: Well, abstracting away some of the functionality means that it's possible to alter some level of internal layout without needing to alter the driver beyond ading IDs
libv: agd5f: apple is not using the same drivers as ati anyway
mjg59: See ACPI for a case where this even basically works
agd5f: makes new asic bring up much easier
ajax: heh. apple
ajax: apple's driver is definitely based on fglrx.
ajax: strings it sometime.
libv: ajax: but it is not fglrx, as they do weird stuff themselves
agd5f: they probably used it as a reference driver
libv: first broken connector table we've come across btw
libv: not that it was the only one
libv: mjg59: so far, the workarounds have been small for all of r5xx and r6xx
libv: mjg59: and would've been even smaller if the mindset wasn't "let's all hide it away anyway"
libv: like shifting all registers up by one position in the middle of a subsystem
libv: plus, feel free to explain how to do a complete save and restore, when hiding everything away into something that doesn't do save/restore. And don't answer "save/restore must go away", as that's just laziness talking
FlyingSpaghetti: i am looking at the reference guides released by ati (the register guide). but there are no application notes...how do developers even know where to begin?
libv: FlyingSpaghetti: :)
FlyingSpaghetti: is there another guide that can give at least any guidance?
gusta1: FlyingSpaghetti: there is no spoon
gusta1: there is no reference. it's just a PR trick
FlyingSpaghetti: damn..
gusta1: seriously, I think they assume very high knowledge in GPU programming already, so they just share the register values, basically
ajax: pretty much.
FlyingSpaghetti: i guess that i'll look at the current source code that the developers here have and try to piece together some things
FlyingSpaghetti: ah, bastards
libv: gusta1: there is no programming reference for this sort of stuff
libv: gusta1: there just isn't
gusta1: quite a lot of the knowledge you need is also very system specific. if you know driver development on win32, doesn't mean you'll know linux..
gusta1: libv, exactly.
libv: gusta1: the only reference there is is the code hidden away in atombios, for those bits that are in atombios
libv: for the stuff outside that, there is no programming guide either
FlyingSpaghetti: i've only worked with the freescale hc11/12 and renesas microprocessors
libv: this is why this whole documentation thing is that hard
libv: well, no, throw IP stuff and lawyers in there as well
gusta1: well, I have just hacked very small parts of the kernel, almost no X, and never ever GPU, so I really don't know, but I'm familiar with programming in general. probably like FlyingSpaghetti
gusta1: i'd like to code for the gpu, to do some calculations there basically, but I've never taken the time to learn where the heck to start... just pci scares me
ajax: mmio is easy.
ajax: if you understand what unary * does in C, you know enough to use mmap'd pci.
gusta1: ok, you have a pointer to gpu memory, sure, but then you'll have to know how to get that pointer... and I'm afraid I'll kill my computer ;)
ajax: the closest i've come to killing a machine due to X hacking is tazing the eeprom on my ethernet card while changing video cards.
FlyingSpaghetti: i'm going to have to figure out this stuff on a high level...then probably use FPGA's to drive the ATI chipset and to process the data...but this is a good place to start i think
gusta1: hah ok
ajax: and that's because the machine in question was pre-production hardware and hadn't been shielded properly
emmes: FlyingSpaghetti: for initialization you definitely need atombios
emmes: during runtime you mostly don't (except for data tables etc.)
libv: emmes: because we don't have the information or the resources to fix up memory and engine initialisation :)
emmes: libv: and you don't want to. full stop.
libv: maybe z3ro will one day manage :)
libv: well, igp is low hanging fruit there
emmes: initialization is just too card specific. too painfull.
libv: other stuff is a lot more complicated
gusta1: if I learn how to code pci (ok, I assume it's simple), can I code for the GPU while X is running, or is that begging for problems?
libv: i thought none of the actual atombios code was to be card specific, just the information in the tables
FlyingSpaghetti: emmes: ok, i will keep that in mind
emmes: gusta1: this is begging for problems, yes.
emmes: but as soon as dri or similar interfaces are in place, you can lock() the card
gusta1: so the crazy supercomputer-guys who distribute processing power on gpu's, they don't use the gpu's at the same time?
emmes: ATM there wouldn't be any problems, because we don't use any registers appart from modesetting and cursor :-P
emmes: gusta1: they do, but they use a higher level interface
emmes: either OpenGL, or CUDA (nvidia), or CTM (AMD)
gusta1: ok, shaders and stuff maybe?
gusta1: yeah ok
emmes: these interface do the locking right.
emmes: well, most of the time ;-)
gusta1: yeah, your cursor code for radeonhd is also correct.
gusta1: most of the time ;)
emmes: ndim: I change the description about out-of-source-dir building in Readme and wiki, because I don't even have 'autogen' installed - and i don't think it's needed any more, the autogen.sh just works(TM)
emmes: gusta1: thank you :-P
emmes: slaps gusta1
ndim: Uhm.
ndim: emmes: That should be "autoreconf".
ndim: autogen.sh messes up.
ndim: autogen.sh runs configure.
gusta1: heh, I wasn't complaining, just making a note, unless you knew. it flickers on certain x-coordinates
ndim: That is a BAD idea.
emmes: ha, so your description was broken ;-)))
ndim: Yes.
ndim: I thought I had that fixed long ago.
ndim: autogen.sh must DIE.
emmes: what is the bad idea with running ../autogen.sh?
ndim: The bad idea with autogen.sh is that it does two steps at once for what is logically separate.
emmes: i don't like remembering '-ihv ..'...
emmes: yes, i understand that one
emmes: and i do not always appreciate. but for the "simple minded" user it's a nice shortcut.
ndim: And if whoever got the idea to use the AM_MAINTAINER_MODE got off his drugs, the --enable-maintainer-mode would not be necessary.
emmes: i also almost always forget the --enable-maintainer-mode
emmes: lol
emmes: agreed.
ndim: That has been broken and deprecated for 10 years or something, but they still used it when they switched xfree86 to the modular build... *SIGH*
luke-jr: lol
luke-jr: any kernel hackers in here?
ndim: My last kernel work was a few years ago.
ndim: BitKeeper times.
luke-jr: it that yes or no? :þ
slackern: Hey everyone, just noticed my screen started to run at 60hz instead of 75hz
slackern: xrandr -q gave me this: 1280x1024 60.0*+ 75.0 59.9
slackern: Anything expected or should i perhaps send in a bugreport in the mailinglist?
libv: Dottout: should be fixed now
libv: well, worked around at least
libv: ergh.
libv: not yet :p
libv: now it is fixed
soc: hi
soc: i heard that amd won't release information about video decoding, is that true?
airlied: soc: maybe maybe not..
airlied: soc: some chips tie the DRM portions tightly with the decoders..
airlied: soc: no final decision has been made.
luke-jr: so implement the DRM in such a case?
luke-jr: or at least enough to handle non-DRM video
soc: mhh
soc: ok thanks ...
soc: airlied: would that mean, if we get no information we have no hardware acceleration regarding video playback?
airlied: luke-jr: we can't implement the drm..
airlied: luke-jr: we aren't a trusted company..
luke-jr: soc: the high-end AMD cards don't have 2D acceleration at all; it's all via OpenGL
airlied: luke-jr: AMD can't legally reveal how it works..
soc: ah ok
luke-jr: airlied: isn't the actual implementation in the chip?
soc: airlied: so what would we actually lose then?
airlied: luke-jr: some parts are some parts may be in the driver..
luke-jr: GPU-accelerated MPEG-2 decoding, I presume
luke-jr: airlied: nothing that can be left out for non-DRM video? O.o
airlied: we can do color-space conversion with 3D...
soc: airlied: opengl? do they use that even on windows for that? :-)
airlied: luke-jr: the problem is revealing the registers..
airlied: soc: no using the 3D engine doesn't imply opengl
gusta1: ok, something is WRONG here... I got my monitor to show a nice picture after changing modes a couple of times, but now after the screen saver (powersave) the mode has been changed Again, and the screen looks like crap (bad clock+phase)..
airlied: luke-jr: legally can't reveal the drm regs, so they are the same regs as non-drm..
soc: airlied: i asked because you said that the highend cards don't have 2d accel at all, that they use ogl, and i wondered if that's true for win too?
agd5f: soc: they use the 3d engine for everything on the new cards
luke-jr: airlied: aren't the regs AMD-specific and thus AMD IP to reveal?
gusta1: 70hz->65hz->70hz->60hz->70hz and I finally get the correct looking 70hz picture.... something, is terribly wrong with the modes in either xserver or radeonhd
agd5f: no separate 2d core anymore
airlied: soc: opengl is a highlevel API. the cards don't implement opengl in hardware.. the driver translates.
soc: ah ok
airlied: luke-jr: they are AMD IP but they have signed contracts which say they can't reveal it..
luke-jr: airlied: wouldn't the Xv implementation use OpenGL tho?
airlied: luke-jr: nope.. Xv would just use the 3d engine to do tesxtured video.
luke-jr: hm
agd5f: luke-jr: it could via something like glucose
luke-jr: glucose… is a sugar?
soc: airlied: so basically someone would have to reverse engineer it ... and exactly that would be the absolute horror for the media mafia, because people wouldn't need to rely on insecure software players or cd-drives to reveal the keys?
soc: am i right?
agd5f: luke-jr: it's a acceleration API that uses opengl
soc: they could just grab it off when it's on the gpu ...
airlied: soc: maybe maybe not. depends on how well implemetned it is..
gusta1: agd5f: better than gallium3d?
airlied: soc: it may not be on the GPU unencrypted..
soc: hopefully
ajax: of course, a sufficiently determined attacker is just going to snoop the pixels as they get shifted into the LCD itself.
airlied: soc: it gets sent to the monitor..
soc: so people won't get in trouble because the want video accel
luke-jr: ajax: that's lossy
airlied: ajax: yes until they HDCP enable your eyes.
airlied: ajax: you know they want to!!
agd5f: gusta1: different. gallium provided an interface to the 3D engine
agd5f: glucose provides an accleration architecture on an existing API that tends to have HW implmentations
soc: i've seen on some diagrams from tungsten that they plan to have a direct3d api too ...
gusta1: yes
soc: will that api be only available on windows or would we be able to piss of ms?
airlied: soc: ou still need the rest of the directX stack
ajax: that's a crystal ball question
gusta1: i think gallium looks really cool, and everyone (incl radeonhd) should try to implement it.. but i'm not the judge..
luke-jr: motions toward WINE
airlied: gusta1: radeonhd is a 2D driver..
libv: gusta1: hrm
gusta1: airlied: forever?
airlied: gusta1: the 3D component may or may not be radeonhd..
libv: gusta1: we plan to eventually provide open source drivers for this hardware
soc: like directx 10 games running on linux faster than on vista and a pr nightmare for "nooooooo win xp is toooooo different for d3d10!!!!!!!!!"-microsft
soc: :-P
libv: for 3d acceleration as well
libv: soc: that will not happen
gusta1: and that 3d acc would not be in radeonhd?
airlied: gusta1: the 3D driver goes in mesa..
libv: gusta1: this is not how the Xorg driver model works
soc: libv: why not?
libv: soc: because ATI wants to keep it's optimisations under wraps still
gusta1: libv: the Xorg driver model works with two drivers per hw? :P
libv: soc: we will at one point have decent performance, probably
soc: libv: ok, then maybe a "direct3d10 runs on linux"?
libv: soc: but not something that will better the catalyst ones
soc: :-/
airlied: in theory if wine reimplemented all of direct3d outside the driver..
luke-jr: soc: that's on the WINE end
gusta1: and why on earth would 3d hw code for ATI go to mesa and not radeonhd? I thought mesa was software-only
airlied: then you could plug in a gallium d3d driver..
libv: soc: it's quite long away still
airlied: gusta1: you don't know much then..
soc: so the only thing ati got right are the optimizations, and they won't publish exactly that?
gusta1: probably not :/
libv: soc: so get your feet back on the ground, and don't let people make your head spin with pipedreams
soc: ok ok
libv: soc: we will go step by step here, not running ahead of ourselves
soc: :-)
gusta1: aaah pipedreams..... *drooling like homer*
luke-jr: so Intel will be the best for gfx for a while?
libv: soc: there are soo many hoops to jump through first
soc: i hope ogl3 will be more important :-)
libv: so it doesn't pay to make big statements knowing that one probably cannot deliver
soc: that would be the prefered solution, instead of running behind ms and trying to implement their stuff
soc: k, understand that
gusta1: I mean, radeonhd is a _new_ driver, supposed to be a very well functional de-facto open source driver for ati cards? supposed to run as default in many distros?
gusta1: how does that rhyme with not having XVideo?
libv: soc: opengl 3 is a standard that is being worked on still, so it is not finished yet
gusta1: i'm sure being able to play movies is more or less something people expect nowadays
libv: gusta1: hardware is no longer able to offer everything an Xv implementation usually offers
libv: gusta1: we will have to "revert" to using the 3d engine
gusta1: uhm.. *turn crypto-speak off*
libv: gusta1: but this sort of thing has been said over and over again
gusta1: sorry for bringing it up one more time :/
libv: gusta1: XvPutImage was meant for hardware video overlays
gusta1: but I really have tried to find info on radeonhd+xvideo on google, wiki's etc
libv: gusta1: the r5xx and up hardware still has a hardware video overlay
libv: gusta1: but... it offers limited scaling (1x and 2x) and only offers a few very rarely used image formats (or FOURCCs)
gusta1: oh, on hw?
airlied: libv: do you know what the hell AMD use it for?
libv: gusta1: so the gain from doing such an implementation would be limited at the moment#
libv: airlied: opengl overlays is what emmes mentioned as a possible use case
gusta1: but (I know you probably hate these questions) xvideo worked "well" in fglrx (ok, that's a lie, but sometimes it did)
airlied: libv: ah that might make some sense.... I've just ignored them..
libv: it does seem like fun to implement this though
airlied: gusta1: they use the 3D engine
libv: hardware will respond nicely
libv: just that it will not deliver what users need
gusta1: the expose an xvideo interface but internally use 3d? oh..
gusta1: that's cheating...
libv: but for someone who wants to have some fun being close to hw, it is perfect
airlied: gusta1: nope Intel open source does the same.
libv: gusta1: it is done quite often these days
libv: gusta1: XGL also "fools" Xv
gusta1: but then my question is valid.
ajax: libv: you could blit from arbitrary fourcc's to whatever the hardware supports in a shader, i guess?
ajax: dirty though
luke-jr: Xgl is an obsolete hack tho :þ
gusta1: no 3d in radeon => no xvideo => people will be dissapointed not being able to see movies
libv: ajax: this is the plan though
gusta1: *cries a little*
agd5f: soc: it's more than just optimizations, alot of ati's code is shared among platforms as probably uses copyrighted MS/SGI/etc. code
ajax: libv: ouch. that's a 3d pipe flush on each frame (unless they have better partial flushing now, which i hope they do)
kdekorte: gusta1, if you have a fast CPU you can still watch movies on radeonhd
gusta1: well, I do, kdekorte, but barely
libv: ajax: as with everything outside modesetting, i have little clue about it :)
luke-jr: agd5f: last I checked, the question was docs, not code?
gusta1: a 720 works more or less. a 1080 does not..
airlied: gusta1: yup 1080 without hw help is hard.
kdekorte: 1080 doesnt work on much, even according the mplayer team
kdekorte: too much to decode
gusta1: at least since most movie players aren't multithreaded
agd5f: luke-jr: ?
luke-jr: agd5f: AMD/ATi's releases are documentation, not code
emmes: airlied: opengl overlays are *extremely* important in the workstation market - too many legacy applications needing it
gusta1: on xvideo (fglrx) it was actually pretty smooth, but then again, that's quite another world than pure cpu decoding
emmes: we probably will never provide it, so fglrx has a real use case
agd5f: luke-jr: yes. but that's why they can't release the src to their windows/fglrx driver, in addition to the optimizations/hacks
gusta1: can't and can't
gusta1: they have lawyers, and lawyers are evil
luke-jr: I don't think anyone wants fglrx code, just docs to write a better driver
gusta1: and, why release windows driver if they really don't have to?
ajax: gusta1: they're not different drivers anymore.
gusta1: well, there's a lot of glue probably
luke-jr: gusta1: someone behind Linux should get lawyers and sue for $ to fund development of a replacement ☺
gusta1: and probably IP and other crap (that's what nvidia used as argument for not open sourcing their driver)
emmes: ajax: there shouldn't be a flush necessary. AFAIK they even have multiple contexts now
agd5f: gusta1: because they don't have docs in many cases. src code is the documentation for a lot of things
gusta1: luke-jr: but sue who?
luke-jr: AMD
luke-jr: nVidia too while they're at it
kdekorte: the ip is a problem, so many of the 3d patents are multiple cross licensed it is a mess
gusta1: agd5f: source code is more. it's man our, it's copyright, it's pride, and it keeps lawyers busy...
kdekorte: that is why fixing the patent system is important
emmes: kdekorte: 1080 in h264 is about 60% load on one of my 4 cores ;-)))
emmes: but not with radeonhd, ATM, i admit
ajax: emmes: you're saying the yuv overlay can snoop on the 3d output cache?
gusta1: I assume what they release can be stripped down to the usual MIN() c-macro. MIN(Get's god PR publicity, Makes lawyers angry)
kdekorte: mplayer running fullscreen here (1600x1200) with a 512x384 source will max out one of my two cores (2.13Ghz)
kdekorte: with the radeonhd driver
gusta1: kdekorte: that's the problem
gusta1: it should use both your cpu's...
agd5f: gusta1: fix mplayer
gusta1: 1280x1024 with a [dunno]x720 source maxes mine
kdekorte: gusta1, lets see your math skills
gusta1: agd5f: no thanks
ajax: emmes: i'm used to video overlays snooping straight from coherent memory and skipping the gpu's pixel cache. if that's not the case, wow.
gusta1: kdekorte: oh no!!!!
emmes: ajax: ah, you meant caches? i thought pipeline. i have no clue about partial cache flushes
kdekorte: any of the mpeg streams can be made multithreaded, it is just quite difficult to do
kdekorte: higher the compression, harder the math
gusta1: uh... well
gusta1: ffmpeg does it fairly well on every codec I've tried (not many, but a few)
ajax: emmes: well, bit of both, although i suppose the pipeline is bounded latency where the pixel cache is potentially forever
gusta1: with dynamically allocating as many threads as I prefer
emmes: and also no clue about where the overlay engine is attached to. in a straight-forward design i would attach it to the cache, but i'm not a hardware designer...
libv: emmes: before DxMODE/SCALE and before DxCRTC
libv: i guess... from having poked it. no docs on such things available though
emmes: right. it could still bypass the cache (as ajax implied)
ajax: i guess we'll find out
emmes: sooner or later.
emmes: hoping sooner ;)
libv: ajax: *shrug* i'm very certain of what i am stating here
libv: ajax: just stating that this was not information provided to us
ajax: nod. i'm just speculating for the mental exercise.
emmes: understood :) perfectly.
gusta1: radeon != radeonhd. why, how?
gusta1: I read radeon got atombios support... but, is the reason for radeonhd to start off fresh and perhaps not support really old (and perhaps different) hw?
gusta1: I never understood this..
libv: gusta1: radeonhd started late july
gusta1: yes, why?
gusta1: we had radeon, right?
libv: gusta1: radeon atombios started not even a month ago
libv: gusta1: no, we didn't
gusta1: well.. uh.. ok....
Zhenech: we had, but without support for r5xx and r6xx
libv: we had avivo, but this the two were not related, and glisse, daniels and mjg59 were partly scratching their own itches, and largely being a very fantastic pressure group on AMD :)
gusta1: but we're talking about ati radeon cards. and we had -ati, and then -avivo, later -radonhd and now -radeon? A lot of drivers for the same card, especially since the latter two both use atombios.... more is less?
Zhenech: gusta: -radeon is -ati
gusta1: ok, which makes the initial statement valid. why did radeonhd start?
Zhenech: which is only for r100-r300 cards
gusta1: oh
gusta1: ok. didn't know.
Zhenech: or it was, now it develops by using the atombios stuff
rx__: is surprised this isn't in the wiki.. radeonhd history?
gusta1: atombios depricates the rXXX-concept?
gusta1: rx__: yes please please something.
Zhenech: no, atombios is just a way to ask the card what it and the connected screens are capable of
gusta1: from the outside, it's almost impossible to know what is what
Zhenech: (libv, correct me if I'm wrong)
gusta1: Zhenech: so -radeon==-ati is still just r100-r300?
Zhenech: it's easy: fglrx for those who want their machine crashed, radeon for older cards, radeonhd for newer
rx__: xf86-video-ati prior to radeonhd did not have atombios support and did not have r5xx/r6xx support
gusta1: because, if it's becoming <=r600, radeonhd seems superfluous
libv: gusta1: atombios handling came from -radeonhd
libv: gusta1: pll came from -radeonhd
rx__: post radeonhd, xf86-video-ati now _does_ have r5xx/r6xx/atombios support
libv: and i am sure that for many more things radeonhd has been helpful
gusta1: i've used fglrx for a year on my x1650, and it's sucked from the very start. ok, it has xvideo and opengl, but.. well..
libv: rx__: to some extent
rx__: sure to some extent ;)
Zhenech: gusta1: nope, radeon will support r500 and r600, but it will be a huge mess if you want to add support for so much families of card to one driver
gusta1: I can start my own driver and probably "be helpful" but why not extend -ati when the specs were released? why start a new?
Zhenech: radeon is oldstyle, radeonhd is like web2.0 *giggles*
gusta1: oh ok
gusta1: omfg
gusta1: shrivers
Zhenech: i'm using radeon right now on my radeon 7000
Zhenech: works perfectly, but the card is sooooo old
gusta1: sucks at card models
gusta1: heh ok
gusta1: sounds new
Zhenech: r100 chip
Zhenech: or even rv100?
gusta1: well, I wonder what part of my r530 is better than yours
gusta1: probably not much
gusta1: that I use anyway
Zhenech: heh, i have only 16mb videoram
gusta1: sure, loads of memory, loads of [cannot use] 3d etc...
gusta1: well, do you need more? :)
Zhenech: so no 3d when I have dualhead setup :(
gusta1: well, with these drivers, there's no 3d anyway
gusta1: or do you mean, even with mesa?
Zhenech: with radeon i have perfect 3d when I have only one screen
gusta1: *just realized how increadibly slow Stellarium is without 3d hw*
gusta1: uh ok...
Zhenech: but none if I use both, as the resolution is to high to fit in the vram
gusta1: so -radeon has 3d-support wtf?
Zhenech: sure
gusta1: i'm getting crazy...
Zhenech: for r100-r300 there is 3d support in radeon
gusta1: there's something about information in the information era that I simply do not get
Zhenech: have a look at http://dri.freedesktop.org/wiki/ATIRadeon
gusta1: I think the internet is a wonderful thing that could contain information, but all it contains is gitweb, pron and blogs.. no real simple structured info...
gusta1: of course I haven't seen that page even tho I've googled for ati/radeon things
gusta1: I hate wiki....
libv: gusta1: technically, it makes no sense to put r500 support in -radeon, imho
libv: modesetting, which is the most work always, is completely reworked
libv: hw video overlay is gone
gusta1: I am (have become, and it scares me) a user. I buy a computer and try to find info on what cards have good open source support, and I find nothing.
libv: all the r500 shares with previous radeons is 2D acceleration, and drm and dri, which are external already, so we just need to implement the interface
gusta1: but now I see, I should've bought an r300
gusta1: and you say it makes no sense? well, most people don't see the code, they see the name
libv: gusta1: we are working on as full as possible open source support for r5xx and r6xx
libv: gusta1: people will start X
gusta1: these stupid users (like me) think a driver called "radeon" probably should support radeon cards ;)
libv: gusta1: and X will at one point load the right driver, based on driver-internal information
libv: a pci-id list
libv: and then things should just work (it never does, but it should, at one point)
libv: gusta1: the driver name is totally irrelevant
gusta1: at one point
libv: it is just a string in the config file
gusta1: libv, excuse me? ok, well. that's it then.
gusta1: to you yes
gusta1: to ubuntu users who don't know init has PID 0 yes
gusta1: to me, the driver name is everything
libv: gusta1: these drivers are all less than 6 months old
libv: gusta1: no distribution is using them for released versions
gusta1: when I buy (parts to) a computer I do as much as possible to find what hw has good open source support
Zhenech: gusta: the new radeons have HD in their almighty marketing names, so radeonhd is a prefect drivername for these
libv: gusta1: a time will come when this hardware has good open source support
gusta1: mine has? ok
gusta1: X1650.. no 'hd' there...
libv: gusta1: we at suse and AMD are very much dedicated to that
Zhenech: the 2x00 series has
Zhenech: the 1x00 not
gusta1: libv: a year ago when I bought the card, I didn't except "a time will come". I really tried to find an _existing_ card with _existing_ decent support..
gusta1: Zhenech: you don't think it's a problem with the name then?
Zhenech: a year ago i would have bought a nvidia, if lenovo had thinkpads with nvidia at that time
gusta1: libv: don't get me wrong, you rock. but the information sucks as with everything nowadays
Zhenech: gusta: for newer cards not, for the 1x00 series - well, it is radeon, but the ati/amd driver is called catalyst? no radeon in there... ;)
gusta1: well, the latest wiki is like kick-ass, so. it's a very good start.
gusta1: Zhenech: ATI's own driver name is just fucking insane, excuse the language.
gusta1: but that says more about them then the card
gusta1: well, the marketing people
gusta1: it took several days before I understood that catalyst actually was the name of a driver targeted My card. I thought it was something new for brand new models... they scared me away. hurray.
Zhenech: gusta: the point is, today xorg works completelly witout a config file, it just decides correctly what drivers he needs
gusta1: yes, in the theoretical world, with einstein
Zhenech: you only need an config to tune non-default options
gusta1: here on earth, xorg.conf is very much needed
gusta1: well...
gusta1: I love the effort put into going away from the conf, but it won't be complete in a long time
gusta1: I need my monitor settings for instance (I even need to give ModeLines!!!) for X to show up _at all_ on one of my screens... so this usual "works without config file", well. yes.
gusta1: for us keybaord, two-button mice and an intel gpu
Zhenech: hehe
Zhenech: well, how would you search for the correct driver for your card?
gusta1: I don't even want to THINK about what happens if I remove my 50 lines of touch-pad config lines on the laptop
Zhenech: heh, clit-mouse for the win :>
gusta1: ok, I must admit I suck at googling, but I'd search for ati and nvidia and intel. and open source.
gusta1: lol
Zhenech: why not asking your distribution?
Zhenech: when i do a apt-cache search x1600
gusta1: ask debian? lol
Zhenech: i get radeonhd
gusta1: uh
gusta1: well
Zhenech: (and fglrx=
gusta1: this was a year ago
Zhenech: a year ago, noone even thought about amd opening the specs
Zhenech: (well, maybe libv did while sleeping with amd's ceo...)
Zhenech: *duck'n'run*
gusta1: well, whatever I search for, it's very very hard to just get the simple info I want ("for nvidia, the proprietary driver is ok, for ati it's complete crap. the open source drivers are both under development and none support any 3D yet, and won't for quite some time")
gusta1: that, would have rocked. now I have ati on one box, nvidia on another, and well.. I had to figure it out myself.
gusta1: so that's a hundred euro thrown away basically...
gusta1: oh, so libv is the bitch? good to know who to pressure info from..
Zhenech: :)
Zhenech: probably someout should launch something like a linux video driver matrix
Zhenech: telling all the pro and cons of the drivers
Zhenech: and the hardware they support
gusta1: well, the way radeonhd works now is enough for me. 3d would be very very nice, but now I can write code, read mail and browse...
gusta1: Zhenech: uhm, like... YES?
gusta1: someone with that knowledge really really should
gusta1: and also add things like dual-head support... I wanted one of those cool intel gpu's with great oss support.. but they only have one output (and usually vga)
Zhenech: because the info you stated above is not entirelly correct
gusta1: regarding the r[1,3]00 3d support, no
Zhenech: for ati there are mainly 2 drivers: radeon and catalyst/fglrx
Zhenech: the first is for old cards only, but opensource, and stuff
gusta1: is radeon ati's driver?
gusta1: thought it was some community reverse engineering...
Zhenech: it is
Zhenech: i meant for ati cards
Zhenech: :)
gusta1: ok
Zhenech: now comes a third one: radeonhd, nice opensource stuff, but early development
gusta1: yes, i read "from" but you wrote "for", me stupid, here late, 2 aclock, should sleep, feel dizzy
Zhenech: 2 oclock here too, damn :)
gusta1: you gotta be german like every one else from suse?
gusta1: or east coast us
Zhenech: ey, I'm not from suse
Zhenech: :P
gusta1: uh... heh, I AM dizzy...
Zhenech: but yeah germany is correct
Zhenech: Tag '1.0.0' created by Matthias Hopf
gusta1: ich denke du müsse schlafe.. omfg
emmes: i have no freaking clue ;)
gusta1: my german has gone to the grave..
rx__: ooh.. egbert updated his blog
gusta1: -08 looks like west cost us
Zhenech: egbert: 185 commits, libv 143 commits, emmes 117 commits, /me 2 commits
Zhenech: looks like I lost ;)
gusta1: well
gusta1: it's all about quality
gusta1: your two lines of code maybe did everything
Zhenech: well, no, that were only documentation fixes
Zhenech: :)
gusta1: as I have said the last hour or so, that IS an important part, so..
gusta1: you da man, prolly
Zhenech: hehe
Zhenech: well
Zhenech: i *should* go sleeping
gusta1: good idea. duten nacht
gusta1: gutan*
gusta1: guten* damn it
Zhenech: gute nacht :P
Zhenech: without the n
gusta1: oh.. no n?
Zhenech: nacht is female
gusta1: ah
gusta1: of course
gusta1: well... my german is better than your sweedish :D
Zhenech: it's just because I do not listen to dimu borgir :P
gusta1: what the Hell is that?
gusta1: googled for it, and got a web page with some freaking animal with chick tits
gusta1: wtf
gusta1: surely diabolic
Zhenech: norwegian black metal band
gusta1: well, we have quite a lot of black metal here if you're into that obscenity ;)
gusta1: no, +force sleep. ciao
Zhenech: n8 gusta
Zhenech: n8 emmes, libv
libv: Zhenech: night :)
libv: now we are going to go off too, see if we can still find a place where they serve beer in this town :)
libv: night all
emmes: nighty nighty to all of you
emmes: it has been a loooong day
emmes: need something to dring *now*
emmes: |*)
rsmith: driver works great! THANK YOU!!!!!!!!!!!!!!!!!!!!!