agd5f: MostAwesomeDude: parts of it
Nyle: MostAwesomeDude, dualhead works but only so-so
MostAwesomeDude: agd5f: Trying to add to the VAP packets an F (fog) command.
Nyle: MostAwesomeDude, applications span across both monitors
agd5f: Nyle: that's a window manager thing
agd5f: need one that's "xinerama" aware
Nyle: also, I like to force a mode like 1400x1050 on my CRT so that I can view alongside my lcd which is 1680x1050, so that stuff doesn't look weird
Nyle: agd5f, kde is xinerama aware
Nyle: kwin
agd5f: Nyle: you can use xrandr to add new modes on teh fly. see xrandr --newmode and --addmode
Nyle: I see
Nyle: i did not know that
Nyle: sweet
Nyle: is there a away to save the settings of xrandr?
GerbilSoft: is there a simple way to calculate a modeline based on a resolution and refresh rate?
agd5f: GerbilSoft: cvt
GerbilSoft: agd5f: thanks
agd5f: cvt 1024 768 60
GerbilSoft: nice :)
GerbilSoft: hm
Nyle: agd5f, for newmode I'd have to add a modeline type ?
GerbilSoft: reducedblanking - would that work on a VGA-connected LCD?
Nyle: and then add that using addmode?
Nyle: agd5f, sorry for bothering you with newbie questios
agd5f: GerbilSoft: yes
GerbilSoft: ok
GerbilSoft: and if i try reducedblanking on a CRT... <_<
agd5f: generally LCD's use reduced blanking
agd5f: GerbilSoft: probably would work fine
GerbilSoft: really? :o
agd5f: most CRTs are pretty good about it nowadays
GerbilSoft: i have a 19" CRT here from 1999
GerbilSoft: wonder how it'd work on that
GerbilSoft: i'll try it later, working on stuff right now <_<
agd5f: Nyle: yeah. use cvt
Nyle: cvt?
GerbilSoft: hm
GerbilSoft: cvt prints out a modeline with 59.92 Hz refresh
Nyle: oh
agd5f: Nyle: it's a utility
agd5f: cvt 1400 1050 60
Nyle: its 30-96, 10-160 (CRT) does 1600x1200 max, I want it to set it to 1440x1050
agd5f: # 1400x1050 59.98 Hz (CVT 1.47M3) hsync: 65.32 kHz; pclk: 121.75 MHz
agd5f: Modeline "1400x1050_60.00" 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync
Nyle: ok
GerbilSoft: why does CVT use a vsync like 59.98 instead of 60.00
GerbilSoft: seems a bit odd
Nyle: agd5f, $>xrandr --newmode mymode 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync
Nyle: $> is prompt, but is that what it should look like|
agd5f: Nyle: yup
Nyle: ahhh
Nyle: freaking SWEET!
Nyle: xrandr is the shiznit!
Nyle: hmm
Nyle: there is grandr for it, but not featurreful, very basic funtions
MostAwesomeDude: agd5f: I am completely and totally confused as to where the actual vertex data comes from and how it's sent to the card. Any pointers?
agd5f: MostAwesomeDude: in mesa via vertex buffers. in ddx, via embedded vertices in the command stream
MostAwesomeDude: So there's not really any pplace to mess with them, then.
Nyle: agd5f, hey thank you very much
Nyle: MostAwesomeDude, I apprecaite your help as well
agd5f: Nyle: np
MostAwesomeDude: Nyle: Least I could do.
agd5f: MostAwesomeDude: I always get lost in the mesa vertex code
Nyle: you want to do more?
agd5f: so I'm nt sure
Nyle: :)
MostAwesomeDude: Nyle: I'm sorta preoccupied working on code. :3
Nyle: j/k anyway
agd5f: the incoming verices are converted to common AOS or SOA formats in mesa
Nyle: oh, now my only problem is to fix this Xinerama type problem, any help on that would be appreciated, take your time.
MostAwesomeDude: My God. r300_render. Why did I never look in this file before?
dmb: because it was hiding from you
MostAwesomeDude: Or I was hiding from it.
dmb: holy shit there is a huge spider in my room
MostAwesomeDude: 16-bit or 32-bit?
dmb: 32 bit
dmb: MostAwesomeDude, now that i take a second look at it, its an 8 bit spider
GerbilSoft: dmb time to get out the NES light gun :)
dmb: lol
dmb: can intel processors run 8bit code?
dmb: or was that the 8080
MostAwesomeDude: Well, you said it was "huge."
MostAwesomeDude: Now, "long," I would know exactly how big that is.
MostAwesomeDude: Or "short."
GerbilSoft: well i remember they maintained backwards compatibility with 8085 on the 8086/8088
eboettch1r: MostAwesomeDude: lies
GerbilSoft: so theoretically you could run 8-bit code on modern CPUs
eboettch1r: my long isn't the same as your long :P
GerbilSoft: (that's why the 8086/8088 had segmentation in the first place :( )
eboettch1r: x86 seems to have a long history of prefering backwards compatibility over actualy working and simplicity -- in software and hardware :P
dmb: GerbilSoft, so you can only use al,bl etc if you want to right the 8bit code?
GerbilSoft: no idea
GerbilSoft: i haven't done any 8085 programming
dmb: yeh
dmb: what was the 8088?
GerbilSoft: and the last 8086 asm program i wrote was a few years back - a simple 1k BSOD simulator <_<
eboettch1r: dmb: FPU
eboettch1r: 8087*
GerbilSoft: eboettch1r: that was the 8087
eboettch1r: err the 8088 I can't recall
GerbilSoft: 8088 was the stripped-down version of the 8086 with an 8-bit data bus
GerbilSoft: IBM used it in the PC
eboettch1r: arg I have kittens raiding my room
MostAwesomeDude: I wish I had kittens.
dmb: so the 386 was the first 32 bit processor?
GerbilSoft: by intel, yes
Nyle: yes
dmb: hmm, the 286 had protected mode
eboettch1r: dmb: 24-bit
dmb: but it didn't have 32 bit support?
dmb: oh, interesting
GerbilSoft: 16-bit data, 24-bit addressing
dmb: eboettch1r, did it still use the segmented model?
dmb: oh, 16bit data
Nyle: my first very own laptop was compuAdd 25.33mhz 386sx 4mb ram 80mb hdd
Nyle: it still runs great
Nyle: :)
dmb: Nyle, you can put linux on that
Nyle: before that I remember black/yellow monitors
eboettch1r: I have a turbosport 386 around here somewhere
Nyle: dmb, it already runs it
eboettch1r: <3 zenith
dmb: Nyle, what distro do you run?
Nyle: floppix
dmb: any X11 working?
Nyle: none
dmb: what kind of video adapter does it have?
Nyle: though windows 3.11 works just fine
dmb: CGA?\
Nyle: dmb, not sure anymore, I can't remember
Nyle: I haven't booted it in years
dmb: oh
eboettch1r: Nyle: mine suffers from a dead cmos battery :/
eboettch1r: and the part is non-standard, I have yet to find a replacement
Nyle: thats a minor irritance, to set the date and setting on boot
Nyle: my battery died too in the laptop, just go to radeio shack and repalce it
eboettch1r: Nyle: this one has issues with no boot w/o cmos battery
dmb: Nyle, i'm sure if you really tried, you can get X running :D
Nyle: eboettch1r, oh
Nyle: dmb, of course, I take pride in my persistence and ability/desire to learn
eboettch1r: and the battery it has is a nicd but it's in an interesting package... with an IC integrated into it
eboettch1r: I can't find a replacemnet
eboettch1r: replacement*
Nyle: tried ebay?
dmb: Nyle, you can use twm as your wm :D
Nyle: twm ftw. ratpoison better for the soul mind and body.
Nyle: pekwm aint bad
Nyle: allin all i still think *box wm's are the best
Nyle: for me anyway
dmb: eh
dmb: Nyle, you use them over one of the modern ones?
dmb: i just use gnome because its simple, and because it works
Nyle: sometimes
Nyle: is a KDE lover
Nyle: I used to use gnome, until KDE got better and xfce became bloated
Nyle: kde 3.5.9 is rock solid and amazingly fast (3.5ghz core 2, 2gb ram)
Nyle: now kde is all I use and dislike gtk entirely, qt ftw.
Nyle: (sorry im a bit opinionated)
Nyle: :)
eboettcher: all three kittens located here are in 'psycho cat' mode :/
MostAwesomeDude: eboettcher: Sounds nice.
MostAwesomeDude: But then again I'm an ailurophile.
Nyle: I am a petophile
MostAwesomeDude: ( ~~)
Nyle: but I only like the tiny animals
Nyle: like kittens and cats, rats, weiner dogs
Nyle: I love birds but they crap too much
eboettcher: MostAwesomeDude: nice until you remember that you have a room full of static sensitive devices and kittens.
MostAwesomeDude: eboettcher: Hehe.
GerbilSoft: bahaha, i'm randomly reading some wikipedia articles
GerbilSoft: "Proprietary, patented optimizations are part of the value we provide to our customers and we have no plans to release these drivers to open source. In addition, multimedia elements such as content protection must not, by their very nature, be allowed to go open source."
GerbilSoft: - ATI, August 2006
MostAwesomeDude: GerbilSoft: I'll see if I can drag up the ATI quote on DRM.
GerbilSoft: i'd love to see it :)
GerbilSoft: so when will the r300 DRI driver get some of these optimizations like not supporting YUY2 and slow 2D :(
eboettcher: MostAwesomeDude: I'm glad we have Alex & John at AMD :P
MostAwesomeDude: Something like "Requiring dedicated cryptographic acceleration on video cards is senseless, superfluous, and puts excessive demand on manufacturers and consumers alike."
eboettcher: well in any case all of these content protection mechanisms fail quickly.
MostAwesomeDude: TBH I think that most of the people at ATI/AMD are good people.
eboettcher: MostAwesomeDude: yes, but we don't see those people :P
MostAwesomeDude: It's only a very small portion of people that make life suck for us code monkeys.
GerbilSoft: marketing :(
GerbilSoft: and/or the people who have to deal with the MPAA
MostAwesomeDude: GerbilSoft: I think the guys that have to deal with the MPAA are fine people. It's the MPAA that are the pain to deal with.
GerbilSoft: that too
GerbilSoft: also crap physics final in 6 hours
GerbilSoft: i probably should study now <_<
MostAwesomeDude: XD
MostAwesomeDude: Yes.
eboettcher: GerbilSoft: what kind of physics test?
GerbilSoft: quantum physics :(
GerbilSoft: waves, theory of relativity, particle/wave duality
eboettcher: I have some cats if you need to due some experiements :P
eboettcher: do*
GerbilSoft: no schrodinger's questions on the test :(
eboettcher: nothing dealing w/ schrodinger's equation? O.O
GerbilSoft: nope
GerbilSoft: physics 201
eboettcher: is this a survey course?
eboettcher: ah
GerbilSoft: not that far advanced into quantum physics
GerbilSoft: but enough to be a pain
GerbilSoft: hm
GerbilSoft: it looks like radeon doesn't properly support interlaced video modes
GerbilSoft: i tried setting my CRT to 1600x1200 @ 75 Hz interlaced, and it caused an invalid scan freq on the CRT and screwiness on the LVDS
Guest23272: mmm
GerbilSoft: no huge loss, but eh <_<
GerbilSoft: oh whoops - 75 Hz interlaced causes hsync to go to 98 kHz on the CRT, out of bounds
GerbilSoft: 60 Hz causes screwiness on LVDS and not a full screen on CRT. woo
Guest23272: File r300_render.c function r300Fallback line 368
Guest23272: Software fallback:ctx->Color.ColorLogicOpEnabled
Guest23272: when i run blendeq
MostAwesomeDude: agd5f: I know AOS is "array of structs". What's Elts?
surfer: i dont think theres any such thing as 1600x1200 interlaced
GerbilSoft: probably isn't
GerbilSoft: but cvt made a modeline for it :D
GerbilSoft: it didn't really work though <_<
surfer: try 1920x1080
GerbilSoft: let's see
GerbilSoft: ah ha, i was using the wrong refresh rate
GerbilSoft: it should've been 30, not 60
MostAwesomeDude: Guest23272: Can't do anything about that particular one. (Yet.)
surfer: or 50 for 1920
GerbilSoft: 1920x1080 is 30 Hz NTSC
GerbilSoft: (for 1080i)
surfer: um
surfer: 1920x1080 is a high def mode
surfer: 50 hz
Guest23272: oh
GerbilSoft: er crap i can't do 1920x1080 without messing around with my desktop config mode right now
surfer: 100 fps
GerbilSoft: surfer: 50 Hz is PAL, and that's interlaced which results in 25 fps
GerbilSoft: 1080p would be 50 fps
dmb: gnome doesn't like it if you change resolutions without its permission :D
GerbilSoft: or 60 fps for NTSC
GerbilSoft: the number specified in cvt is the framerate, not vsync
GerbilSoft: i'll try 1080i later, need to study physics
dmb: i love the gloss demo thats in mesa/progs/demos
dmb: so shiny!
joecool: hrm.. console switching is broken when i use radeon on r500
joecool: though i guess its better to have backlight control, then consoles.... (no backlight control on radeonhd)
dmb: joecool, console switching works for me
dmb: joecool, what card? what happens when you try to switch
joecool: X1400
joecool: lemme correct
joecool: Radeon Mobility X1400
joecool: dmb: i get some weird colors... etc
joecool: but when i switch back to X, its all good
dmb: joecool, weird, i have that exact card
dmb: joecool, are you using a framebuffer?
joecool: yeah, vesa
dmb: joecool, yeh, from my expirence, vesa + radeon driver don't work
joecool: not vesa-tng, just regular vesa (aka vesa-rrc)
dmb: joecool, if you don't use the framebuffer, console will work fine
joecool: dmb: the odd part is though... it worked on radeonhd
dmb: joecool, yes, it does
joecool: i guess the big question is...
joecool: where do we stand right now between the two drivers?
dmb: maybe file a bug about that, but its not going to get much priority, because console framebuffers are going to be outdated
dmb: once kernel mode switching comes :P
dmb: joecool, radeonhd can't do 3d+2d accel
GerbilSoft: will modeswitching help fix some suspend/resume problems i've been having
GerbilSoft: i.e. occasionally when resuming, i just get a black screen and nothing responds
GerbilSoft: (using vesafb right now)
dmb: think so, airlied would know :D
joecool: dmb: does using a framebuffer effect in-X performance?
GerbilSoft: :)
dmb: airlied is the kernel modeswitching expert
joecool: s/effect/affect
dmb: joecool, don't know
GerbilSoft: last i checked the kernel modesetting branch only had up to R400
dmb: dont think so
dmb: joecool, is your laptop a e1705?
dmb: GerbilSoft, not ready yet :/
GerbilSoft: i know :(
GerbilSoft: oh hey there was a commit that added something for r500
GerbilSoft: not sure if it actually works for modesetting, so i'll wait for now
dmb: what tree are you looking at?
GerbilSoft: http://gitweb.freedesktop.org/?p=mesa/drm.git;a=shortlog;h=modesetting-101
GerbilSoft: commit in question was http://gitweb.freedesktop.org/?p=mesa/drm.git;a=commit;h=c06096d34fa4afb3f24d610ccfb385f92dbc1e83
GerbilSoft: though that's probably just merged from master
dmb: i think modesetting requires a special mesa and drm driver
GerbilSoft: probably does
GerbilSoft: looking at the radeon_ms_ stuff indicates it doesn't support r500 yet
dmb: i think glisse was working on it
dmb: don't know about r5xx
MostAwesomeDude: Can always add it later.
dmb: GerbilSoft, with radeonhd, do you expirence and issue sometimes when you switch to console mode where it is like scrammbled (the text)?
GerbilSoft: haven't used radeonhd in a while
dmb: http://gitweb.freedesktop.org/?p=users/glisse/xf86-video-kms.git;a=summary is the kernel mode switching for radeons
MostAwesomeDude: Argh, this is seriously such a headache.
joecool: dmb: i never had the issue with radeonhd, only radeon
joecool: ..... then again, i just went to 64-bit on this system and moved to radeon
joecool: i've yet to try radeonhd on 64-bit
dmb: joecool_, btw, where in NJ are you from :D?
dmb: is a new jersyian as well
joecool: hunterdon
MostAwesomeDude: I may just give up and ask airlied to do this. I can't understand this at all.
dmb: joecool, ah, i live in basking ridge atm, but i dorm in mahwah, nj for college during most of the year
joecool: yeah, basking ridge is about 30 minutes ride from here
dmb: this whether sucks lately doesn't it :(
joecool: here is readington twp to be specific... our claim to fame was the FBI shootout
dmb: supposed to possibly touch 100 tomorrow
dmb: would (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/dri/r300_dri.so: undefined symbol: __driCreateNewScreen_20050727) mean that my x version is too old?
mikkoc: dmb: yes
dmb: oh
hifi: dli: update your libGL
hifi: umm, sorry, meant dmb but he quit
dli: hifi, don't worry
hifi: btw. why would a function name have a date extension?
hifi: some sort of compatibility check?
MostAwesomeDude: hifi: More likely an indication of an unstable or transitive API.
airlied: its an API marker.
airlied: drivers can provide all the entrypoints if they really want to remain compatible.
MostAwesomeDude: airlied: Afternoon.
MostAwesomeDude: Or evening.
airlied: evening I think.. public holiday so it doesn't matter :)
MostAwesomeDude: Lucky.
MostAwesomeDude: airlied: Any ideas on how to emit additional thingys into the VAP?
MostAwesomeDude: It's not even that big. I just need to also upload the FogCoord from each vertex as a Fog coord for the card.
MostAwesomeDude: The Nyquil dulls my head too much. I can't think.
airlied: MostAwesomeDude: you just need to figure out how mesa puts it into the vertex code..
airlied: it has to be in one of the vertex attributes
MostAwesomeDude: airlied: Already did. It's called FogCoord, and it's in each member of vertex_buffer.
airlied: btw there are a few types of fog, so don't confuse em all :)
airlied: memory says per-vertex and per-fragment fogs exist..
MostAwesomeDude: I think I understand the differences.
airlied: but I could be hazy on it.
MostAwesomeDude: We're going to always use the HW fog.
airlied: MostAwesomeDude: the HW may do a few ypes.
MostAwesomeDude: Right.
MostAwesomeDude: The HW takes a depth value when it receives vertices.
airlied: lemme look at for coord
airlied: fog coord even.
MostAwesomeDude: Then it does a bunch of transforms. Both VP and FP can change the depth value.
MostAwesomeDude: Then at the end, the fog HW does fog based on a couple of OGL-compatible settings.
MostAwesomeDude: Doing fog_coord is just a matter of forcing an app-defined value for fog depth when the vertex is first uploaded.
airlied: jezz I hate fog.
airlied: i915 avoids a lot of fog things with comments.
MostAwesomeDude: I enjoy fog, TBH. Makes even the worst skyboxes tolerable.
MostAwesomeDude: Not to mention that the Radeon makes fog pretty straightforward.
airlied: so there is VERT_ATTRIB_FOG
MostAwesomeDude: Yes.
airlied: so that is the way it gets passed into the vertex code.
airlied: the r200 does some of it already.
airlied: in its VP code.
airlied: we just need to route that into the vp somewhere.
airlied: which I think should happen with the normal code.
airlied: the question then is how it gets to the FP..
MostAwesomeDude: I'm using progs/tests/fogcoord.
MostAwesomeDude: No special FP.
MostAwesomeDude: It needs to be transformable by VPS and FP both, before reaching the end.
MostAwesomeDude: BRB
joecool: i noticed something
joecool: some images on sites make the radeon driver go insane
joecool: screen flickers and the flickers look like the pictures strected to the whole screen
joecool: *stretched
joecool: brb though
MostAwesomeDude: Back.
airlied: MostAwesomeDude: I wonder if I can get it working with swtcl first.
airlied: so at least the FP bit works.s
airlied: so at least the FP bit works.s
airlied: oops.
MostAwesomeDude: XD
MostAwesomeDude: I dunno. I was going to pass it as a param or const to FP, but it needs to be available to VP too.
MostAwesomeDude: It just seems to me like it would be more correct to pass it as depth, or color #4's alpha.
airlied: MostAwesomeDude: you need to route it from the VP to the FP somehow.
airlied: via the rasterizer.
MostAwesomeDude: airlied: Should already be done.
airlied: MostAwesomeDude: don't see any code dealing with it :)
airlied: granted I'm a lot happier in the swstcl paths :
MostAwesomeDude: airlied: The fog value leaving the VP should magically be passed to the fog regs, at least.
airlied: MostAwesomeDude: there is very little magic stuff anymore.
airlied: the VP is all generic, its just a matter of saying wihch outputs go where.
airlied: then route that into the FP in the right place.
MostAwesomeDude: Ah.
MostAwesomeDude: Well, if I'm reading this right, the Radeon has a separate path for fog and depth as two separate values.
MostAwesomeDude: Or, we could always pass them in color #4, but that would be a pain.
MostAwesomeDude: And we'd have to move fog into FP.
airlied: it used to be fog was in color 1 alpha bits.
airlied: but then we have discrete fog as well.
airlied: then I get lost :
MostAwesomeDude: Well, we can keep passing for in color 1's alpha.
MostAwesomeDude: *fog even.
airlied: MostAwesomeDude: we need to figure out all the "fog" paths.
airlied: and what hw to use for them.
airlied: is fog coord == discrete fog.
MostAwesomeDude: Mm, fog coord == use app's value for that vertex's fog instead of depth.
MostAwesomeDude: Don't know what discrete fog is.
airlied: MostAwesomeDude: the r500 docs talk about discrete fog
MostAwesomeDude: Yeah, I'd say that's it.
MostAwesomeDude: So we have to modify both VP and FP, then.
MostAwesomeDude: Need to move either passed-in coord or depth to the fog output on VP.
MostAwesomeDude: Then need to somehow make it work with FP, too?
airlied: yup..
MostAwesomeDude: Does that seem coherent, or just more rambling?
airlied: I'm just looking at swtcl bits..
airlied: my first test hung my card :)
MostAwesomeDude: Okay, so looking at the spec again, it seems like VP shouldn't get a chance to modify fog coords.
MostAwesomeDude: Only FP.
airlied: you need to route it via the VP in any case
MostAwesomeDude: Yeah.
MostAwesomeDude: Argh, I just don't understand the VAP/VPS upload at all.
MostAwesomeDude: It looks like a bunch of spaghetti with no actual meat.
airlied: MostAwesomeDude: hence why I'm hitting swtcl first :)
airlied: http://pastebin.com/m5ed0442a
airlied: is my initial crackery.
airlied: I think 14 is the correct routing for fogc.
airlied: for swtcl
airlied: also GL_FOG_COORD_SRC seems to impact on it.
airlied: hmm GB_SELECT.FOG_SELECT
Nyle: hi
Nyle: I am using debian sid + x1900xt + radeon $>glxinfo|grep dir
Nyle: direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
Nyle: OpenGL renderer string: Mesa GLX Indirect
Nyle: how come I have no 3d when its supposed to have 3d?
Nyle: isn't it?
airlied: MostAwesomeDude: need more revenge tests :-)
Nyle: direct rendering is required for many things and I would like to use it, please advise more. thank you
airlied: Nyle: swwhat does LIBGL_DEBUG=verbose glxinfo say.
Nyle: http://paste.debian.net/5875/
airlied: Nyle: your libGL and r300_dri.so are different.
Nyle: why?
airlied: Nyle: you need to install the libGL you built with the dri file
Nyle: I did not build anything
Nyle: using xorg radeon driver pacakge
Nyle: r500 driver
Nyle: x1900xt
airlied: Nyle: so you didn't install mesa? you won't get 3D support without that.
Nyle: airlied, usually I use fglrx
Nyle: first time on radeon, I intalled mesa-utils xorg and use radeon driver
Nyle: what do i have to do to get 3d to work?
airlied: Nyle: what distro you using?
Nyle: airlied, debian packages used not build anything
gustaf1: Nyle: you have to wait for new debian packages
gustaf1: Nyle: or build them yourself (which I don't recommend unless you _need_ 3D)
Nyle: ah
Nyle: I can build it
Nyle: where do i get the source the build scripts?
gustaf1: Nyle: your last two sentances doesn't match
Nyle: insert comma after source?
Nyle: try to make sense of out it,I dunno
gustaf1: Either you can build them (and need to help with that, or go to #debian) or you can't ;)
Nyle: so you prove source without any build scripts
Nyle: no make files nothing?
gustaf1: you need drm/mesa from git, merge that with old debian source packages (not trivial) and then build.
Nyle: just plain code?
Nyle: im sorry what are you saying to meI don't understand
Nyle: please clarify
Nyle: gustaf1, oh, ok
Nyle: that doesnt' sound too difficult
gustaf1: Nyle: good luck. I have hoped for a long time that the debian maintainers would have done this, but they haven't. so obviously, it's not trivial.
Nyle: gustaf1, the merging you'll have to pay me for
airlied: if you don't care about packages you can just install all the bits..
gustaf1: airlied: sure
Nyle: gustaf1, building from GIT formyself is another story
Nyle: gustaf1, I pacakge for debian sometimes
gustaf1: that's when you get a half-debian half-homebrew system.. that's the beginning of the end ;)
Nyle: last I did a game,packaging took 70+ days
Nyle: I'm not sure why you assumed I'm a tard with comptuers...
gustaf1: Nyle: could have been this: "Nyle: where do i get the source the build scripts?"
gustaf1: if you're a debian packager, you should know, that's all
Nyle: gustaf1, being lazy could use a direct link
gustaf1: Nyle: oh ok. well ain't get none
gustaf1: s/get/got
Nyle: gustaf1, ok, sorry to disturb your great highness.
Nyle: Its my fault anyway, I asked for too much.
gustaf1: jesus... relax.
airlied: isn't the ubuntu packages.
airlied: you could like just run them.
gustaf1: yeah, I run unofficial ubuntu packages in debian.
Nyle: gustaf1, living dangerouly I see
gustaf1: that works, but only half way. I still need xserver 1.5
Nyle: gustaf1, I am sorry that we got off on the wrong foot.
gustaf1: which needs all the drivers with the new ABI (4 not 2)
gustaf1: Nyle: yeah
airlied: gustaf1: is there X on the edge pacakags
gustaf1: Nyle: what you might need for well-functioning X with radeon (at least I do) is -radeon, drm, mesa, xserver 1.5 and all the freaking X drivers.
gustaf1: airlied: I have no knowledge at all about ubuntu.. I got a link to unofficial ubuntu packages of mesa/drm
airlied: https://launchpad.net/~xorg-edgers
airlied: well everyone should be running Fedora :0
gustaf1: yes exactly
gustaf1: exactly about the link, not fedora :P
gustaf1: desperately waiting for xserver 1.4.99 in debian experimental
airlied: ah well dinner time.. bbl
mcgreg: glisse: you still havent pushed your anti-lockup-code into master, did you?
MrCooper: mcgreg: he hasn't
glisse: nop still hasn't i don't know if i merge this one or if i try another solution
glisse: my solution still lockup when you launch several gl app and move window over each other
glisse: there is a sync problem btw the 2d engine and the 3d engine
rschmidt: hey guys, anybody willing to lend me a hand on getting this Samsung 460Dxn working with the radeon drivers? It seems that the latest drivers don't enable the output properly (giving me a black screen but X reports no errors and stays stable)
agd5f: rschmidt: sure
adamk: rschmidt, Can you pastebin your /var/log/Xorg.0.log file somewhere?
rschmidt: agd5f: if you recall, we worked a little on it a few weeks ago... I got ripped off of this project and assigned to something else temporarily, but I'm back, and I have all the dev stuff needed to get going
rschmidt: yup, I'll do that, adamk
agd5f: yup
rschmidt: I recompiled from git on Friday... should I update + recompile before we start again?
rschmidt: ehh, I'll do it just in case.
rschmidt: Xorg.0.log is here: http://www.pastebin.ca/1042906
rschmidt: xorg.conf is here, but it's a pretty generic auto-generated file: http://www.pastebin.ca/1042907
agd5f: rschmidt: what's the native mode of your panel?
rschmidt: 1366x768 @ 60Hz.
rschmidt: I'll set the modeline just to make sure, but the display isn't complaining about invalid resolutions, and in my experience, it's pretty flexible
adamk: Can you ssh in, set DISPLAY=:0 and use xrandr to adjust the resolution?
rschmidt: sure, I'm already logged in via SSH
rschmidt: much too painful otherwise ;)
agd5f: rschmidt: http://www.botchco.com/alex/xorg/rschmidt-test.diff
rschmidt: thanks agd5f, will recompile in a second
rschmidt: adamk: hmmm, that's interesting... if I set no modes in the Monitor section, I get only 1280x768 available (which is a mode the panel can display), but nothing else
rschmidt: if I add a 1368x768 modeline (generated by gtf), it's available, but it's also the only one.
agd5f: well it's deafaulting to VGA as nothing s detected as attached
rschmidt: agd5f: yeah, it lists VGA and DVI as outputs but they all report as disconnected
agd5f: yup
rschmidt: I'm a little rusty on patch... is it just 'patch -p0 blahblah.diff'?
agd5f: patch -p1 -i rschmidt-test.diff
rschmidt: aha, thanks
rschmidt: no visual change after recompile... posting logs
agd5f: rschmidt: can you send me your bios? or did you already?
rschmidt: http://www.pastebin.ca/1042922
rschmidt: the bios? Like the ATOMBIOS?
rschmidt: I don't think I sent any bios stuff to you so far.
agd5f: the video bios
agd5f: ok
rschmidt: just let me know approximately how to dump it and I'll be glad to send it over
agd5f: rschmidt: whoops, cut and paste error in the last patch
agd5f: change radeon_output->MonType == MT_DFP to radeon_output->MonType = MT_DFP
agd5f: and try it again
rschmidt: ok, will do.
rschmidt: hmmm, I'm having trouble getting git to give me back a fresh copy of the patched file...
MrCooper: rschmidt: git diff >local.diff; patch -p1 -R
MrCooper: git reset --hard
rschmidt: aha, thanks
MrCooper: np
rschmidt: ah, there we go... I did a git reset but it didn't replace the file I had removed
MrCooper: git checkout
rschmidt: aha
rschmidt: no visual change, log is here: http://www.pastebin.ca/1042958
agd5f: rschmidt: try this one: http://www.botchco.com/alex/xorg/rschmidt-new.diff
rschmidt: all right, thanks
agd5f: revert teh old one first
rschmidt: are these patches cumulative, or should I start from the fresh git head every time?
rschmidt: ah, okay, thanks
agd5f: rschmidt: hold on. are you sure this is the right log?
rschmidt: fairly sure, unless I made a braindead mistake... why?
agd5f: because DVI-0 should be connected
rschmidt: hmmm... lemme try running it again, making sure I have a fresh log
rschmidt: I just ran it again, it still says DVI-0 is disconnected.
rschmidt: but lemme try with your new patch. I'll archive the other version so we can test again
rschmidt: whoops, hold on, I may have been testing with the wrong driver entirely.
rschmidt: well, same driver, but the version I compiled last week, and not the ones we were working on... give me a sec to clear this up.
agd5f: k
rschmidt: hmmm, that's pretty strange... my prefix is properly set but it seems make install was installing to /usr/local instead of /usr. I'll run a couple of tests and regenerate the logs.
rschmidt: oh oh oh!
rschmidt: I have something on the screen with your latest patch :D
rschmidt: wow, this is great! I'll upload the logs.
rschmidt: latest logs are here: http://www.pastebin.ca/1042979
rschmidt: screen is displaying properly, a little offset, but I'm going to try a few things, check the mode it's running in, etc.
rschmidt: oh, and it's reporting two DVI connections, and both of them seem to be active.
agd5f: rschmidt: please try the old patch again, so we can determine which output is actually used
rschmidt: yeah, I'll do that right now.
rschmidt: agd5f: the original patch fixes the problem (after changing the == for an =)
rschmidt: pasting log now
agd5f: rschmidt: cool. looks like the bios is correct, just not edid on the panel
rschmidt: excellent
rschmidt: the only thing that's a little weird is that the display is kind of wrapped around the panel
agd5f: rschmidt: might need to tweak the mode a bit
rschmidt: the right edge of the display is skewed about 3 inches to the left, and I can see the leftmost windows on the right side
rschmidt: yeah, that's what I'm working on now
rschmidt: I'm not too worried
agd5f: rschmidt: does this thing have a VGA output?
rschmidt: agd5f: Nope! No external outputs whatsoever.
agd5f: ok cool
rschmidt: with your original patch, it says it has a VGA and a DVI output, but only the DVI is connected
rschmidt: which is fine.
agd5f: right, I'll add a quick for your parituclar chip and remove the VGA
agd5f: quirk
rschmidt: okay... hopefully this won't break anyone else's stuff, I don't know if this card is only used for this type of situation
rschmidt: it's really the combo of the video card + the built-in display that's particular.
rschmidt: although... for all intents + purposes, it's pretty much a giant laptop.
agd5f: rschmidt: sort of. looks like it doesn't use LVDS. uses DDIA
rschmidt: it's possible... I'm really not much of a hardware geek; I may have misidentified the internal cable as LVDS
rschmidt: although the cable itself *looks* like a laptop's LVDS cable, I wasn't 100% sure it really was one
agd5f: no worries
rschmidt: I just knew it wasn't regular VGA or DVI.
rschmidt: anyway, thanks for all your help
agd5f: unfortunately, the subsystem ids are the same as the the pci ids. :-/
agd5f: I wonder if anyone else has those subsystem ids...
rschmidt: you mean the video card's PCI ID? are you worried it could conflict with a real card in other systems?
agd5f: rschmidt: what model tv is this again?
rschmidt: This is a Samsung 460DXn
agd5f: rschmidt: not pci ids, the subsystem ids, which are supposed to be unique to the oem
rschmidt: ah, I see
agd5f: well, they are all pci ids I guess
agd5f: just one is the chip id, the other is the oem id more or less
rschmidt: right, but more like a unique ID than an address.
rschmidt: right, like a MAC address is supposed to be unique.
agd5f: rschmidt: more like chip ids: ati radeon x1200, subsytem ids: samsung 460DXn
rschmidt: aha.
rschmidt: this is the log from your original (fixed) patch: http://www.pastebin.ca/1043008
rschmidt: if there's anything I can do to probe for an subsytem ID, or something like that, please let me know.
rschmidt: agd5f: is it possible your first patch was setting a mode all the time? I can't seem to adjust this modeline, nor switch the display to something other than 1366x768
agd5f: rschmidt: ?
agd5f: rschmidt: hmmm. perhaps it's not DDIA
agd5f: try the second patch again
agd5f: and try turning off either DVI port
agd5f: and see which one actually turns the display off
rschmidt: ok, will do, thanks
gustaf1: heh I just misspelled freedesktop into kind of an opposite - feedesktop...
rschmidt: heh
rschmidt: agd5f: with the second patch, DVI-1 is the 'real' display ('xrandr --output DVI-1 --off' blanks the screen while 'xrandr --output DVI-0 --off' does nothing)
Nyle: haha
Nyle: fee
agd5f: rschmidt: so it sounds like it's DDIA
agd5f: rschmidt: can you send me the output of xrandr --verbose?
agd5f: or pastebin it
sn9: any devs get displayport hardware yet?
rschmidt: agd5f: done! pastebin is here: http://www.pastebin.ca/1043064
GerbilSoft: wtf, some recent update added 2048x1536 to the modelines for my CRT
GerbilSoft: and it works :O
GerbilSoft: ...and what do you know, reducedblanking works on my CRT :O
GerbilSoft: well kinda - the edges are cut off <_<
MostAwesomeDude: airlied: I didn't have a chance last night, 'cause I fell asleep, but your initial swtcl stuff softlocked my card.
rschmidt: agd5f: I think your patches do lock the output to a certain resolution...
rschmidt: agd5f: you commented this line: RADEONAddScreenModes(output, &modes);
rschmidt: and replaced it with: modes = xf86CVTMode(1366, 768, 60.0, TRUE, FALSE);
rschmidt: in radeon_modes.c
agd5f: rschmidt: yeah that just adds that mode since your monitor has no edid
rschmidt: agd5f: ah, okay.
agd5f: rschmidt: you should be able to add other modelines via xrandr
rschmidt: agd5f: I'll try that... I'm still having trouble adjusting the screen
agd5f: rschmidt: xrandr --newmode ... and xrandr --addmode DVI-0 ...
rschmidt: thanks, doing that now, just regenerating modelines
Nyle: hello gooeys
Nyle: whats up bredren
rschmidt: agd5f: This is strange... xrandr seems to create the new modes, but it won't let me use them (it says, for example, 'cannot find mode 1360x768', or 'cannot find mode TEST')
agd5f: rschmidt: did you add them to the output using xrandr --addmode?
rschmidt: I believe so, lemme try it again...
rschmidt: ahhh, specified the wrong adapter on --addmode. my bad.
rschmidt: I mean wrong output.
airlied: MostAwesomeDude: and mine :)
airlied: MostAwesomeDude: need to fix up some RS routing for the FOGC
MostAwesomeDude: airlied: Yes.
MostAwesomeDude: But I did some more reading, and it says that discrete fog is "post-tcl".
MostAwesomeDude: That means that we have to upload it AFTER tcl, right? But how does that work?
airlied: MostAwesomeDude: with swtcl, I don't have to worry about the VAP stuff :)
MostAwesomeDude: XD
airlied: MostAwesomeDude: it makes it easier to just get the FP bit right first.
MostAwesomeDude: But, I mean, we DO have to upload the vertices at some point, right?
airlied: MostAwesomeDude: I did with that patch..
airlied: MostAwesomeDude: the vertex info comes from mesa.
MostAwesomeDude: ...Patch didn't really work...
airlied: MostAwesomeDude: I didn't say it worked...
airlied: MostAwesomeDude: I said I set the vertex upload up.
MostAwesomeDude: Ah.
MostAwesomeDude: Silly me. :3
airlied: you need then use the rasteriser to do the next bit
MostAwesomeDude: Okay, well, lemme set up the FP to respect fog.
MostAwesomeDude: If it doesn't already.
MostAwesomeDude: Done. FP will now respect fogcoord.
airlied: now just need to fix the RS :)
MostAwesomeDude: And I'm assuming that Mesa knows to correctly set fragment.fogcoord.
airlied: MostAwesomeDude: it should do..
airlied: the question now is how to link the rasterreiser to route the fog bits to the FP.
MostAwesomeDude: If it sees fragment.fogcoord, it should just set InputsRead & FRAG_BIT_FOGC.
airlied: so we just need to add some RS code to stick FOGC into the pixelstatck somewher
MostAwesomeDude: And then, after we're sure that the RS is feeding us, we can just add a bit to the FP to depthwrite the fog.
MostAwesomeDude: Well, I added FOGC after the texs and colors, why don't we put it there in RS, too?
airlied: just need to figure out where to put it, I assume a color instrcution
MostAwesomeDude: ...I hope my r3xx FP edits work too.
MostAwesomeDude: ...Can't we just cut 'n' paste the COL1 stuff and set it to FOGC in COL2?
airlied: MostAwesomeDude: depends on where tou want to shove FOGC :)
MostAwesomeDude: airlied: Ideally, I'd shove it into a dedicated fog input in the RS.
MostAwesomeDude: But I guess we can just place it into one of the unused HW colors, since Mesa only needs two.
MostAwesomeDude: And we have...four HW colors?
airlied: yup use one of them, the RS only has color and texture inputs
OipOS: glxgears crashes on me with latest mesa: http://pastebin.com/d7e9e91e1
OipOS: After commenting out common/dri_util.c:438, it stops.
MostAwesomeDude: OipOS: Hmmm.
OipOS: latest meaning git, just in case.
girrr: Does anyone know if this driver supports the GL_EXT_framebuffer_object (I can't see it with glxinfo) with the X1950 Pro or is it just the hardware that's lacking support?
MostAwesomeDude: girrr: No and no.
MostAwesomeDude: The HW supports it.
MostAwesomeDude: But the driver does not.
girrr: MostAwesomeDude: thanks, then I know
MostAwesomeDude: airlied: Okay, I've done a bit of RS experimenting. Haven't killed the card, but haven't gotten it all working yet. Will be back later.
gustaf1: Nyle: did you build drm/mesa/xserver/drivers for debian? :)
Nyle: I've been ill lately, sleeping mostly I got drunk last night
Nyle: nothing yet, I been cleaning my house all day
gustaf1: oh, one of those days... that's painful. clean drunk sick.
Nyle: eh, I got today and tommorrooow off
Nyle: I work for a jeweish company's IT dept
Nyle: so its thier new year, and I'm off
gustaf1: I've had issues with a scrambled cursor, but now I just tried to rotate one of my monitors using xrandr --rotate, and now the cursor isn't shown at all on that monitor
gustaf2: great, it killed X too... wtf.
gustaf2: have someone tried rotation with -ati? like, at all?
agd5f: gustaf2: works fine here
agd5f: test on r1xx-r5xx
gustaf2: i'm moving to software cursors.. but then there's another issue.. stupid f*cking X... I need to use a larger "Virtual" to make rotation work. now I have a large space where my cursor can move, but where I can't see nothing. just like when I had my two old different-sized monitors...
gustaf2: I'm going nuts, X is really not liking users
Flice: hi
Flice: does the radeon driver support vide playback (xvideo) on RV670?
agd5f: Flice: no accel on r6xx yet
Flice: agd5f: will I get acceptable performance without acceleration?
surfer: for playing videos maybe
surfer: but u won't like the experience
agd5f: Flice: depends on what you consider acceptable :)
surfer: of other things
Flice: agd5f: no frame drop
Flice: surfer: why won't I?
surfer: videos will play fine... but imagine using windows without installing ur graphics drivers
Flice: surfer: umm?
agd5f: Flice: depends on the format and your CPU etc.
Flice: agd5f: c2d 2.3Ghz. 1024x768, say?
agd5f: Flice: I dunno. test your video and see what happens
Flice: is pretty tired of setting up the card at this point
gustaf2: software cursor: no corruption, no invisible cursor on rotated monitor. conclusion: hardware cursor is severely broken.
Flice: fglrx has vsync issues in video, radeonhd appears to not be ready... looks like I'm stuck with windows
Flice: sighs
surfer: can't argue with ur logic there
surfer: u could just buy a cheap r5xx card
surfer: good (and getting better every day) oss linux support
surfer: and just plug in ur r6xx some day when it's supported
Flice: surfer: unfortunately, I don't have extra cash for that
Flice: and I just don't want to spend it. will probably stick with windows until radeonhd supports my card
Flice: btw, if I were to buy a temporary card, I'd take an older nvidia at this time
surfer: me too
surfer: heh
surfer: if ur goal is a htpc the geforce fx 5xxx is more than sufficient
Flice: well, I was relying on fglrx in the worst case. who could have imagined it had this issue with video
surfer: i wouldn't be surprised if fglrx never worked right
surfer: ever
Flice: no, I also use to play games in dual-boot. one more reason not to replace the card right now
joecool: just don't use xvideo on fglrx
joecool: should be mostly fine then
joecool: more important question from me though... does using a console framebuffer slow down 2d performance in X?
Flice: joecool: this makes another task I can't do in Linux. I can live with rebooting for games, but no video is too much
surfer: no
surfer: but u can't use the radeon fb driver and radeon x driver at the same time
surfer: u could use uvesafb+x though
Flice: is anyone aware of fglrx support channel, btw?
joecool: surfer: i'm using plain old vesa right now
joecool: Flice: #ati
Flice: joecool: thanks
joecool: (its in topic btw)
Flice: joecool: umm, double thanks :)
joecool: surfer: i notice though, with radeon driver console switching is broken if i use a framebuffer
joecool: with radeonhd it is not... but radeonhd makes my backlight control not work unless i switch to console
MostAwesomeDude: RTFM_FTW: Comcast problems?
RTFM_FTW: nah just fucking around with my network
MostAwesomeDude: Ah.
agd5f: airlied: is there any reason for RADEONSetAgpBase()? maybe real old drms?
airlied: agd5f: probably also maybe suspend/resume if the kernel didn't do it
agd5f: should be setup in the drm resume path as well
airlied: then sounds like just ancient drm maybe, or else the usualy bonghits of userspace doing shit it shouldn't
MostAwesomeDude: Userspace is a stoner?
MostAwesomeDude: It all makes sense now.
agd5f: smells like bonghits
marcheu: agd5f: does the r300 have a FLR (floor) instruction in the pixel shader instruction set ?
MostAwesomeDude: marcheu: Not in HW, it's done with FRC and pre-sub MAD.
marcheu: yeah saw that in the source
MostAwesomeDude: But no, there's not a FLR in HW.
marcheu: yup thanks
MostAwesomeDude: ...Do I want to know?
marcheu: know what ?
MostAwesomeDude: Why you were asking about FLR?
marcheu: it's a cool instruction really
MostAwesomeDude: XD, definitely.
MostAwesomeDude: Just seems like an odd query.
marcheu: right, I'll ask when I can play doom3 on my r600 then
MostAwesomeDude: Ah, that sounds more familiar.
MostAwesomeDude: Actually, I'm trying to figure out WTH to do to make fog coords work.
MostAwesomeDude: Know anything about it?
marcheu: the old extension ?
MostAwesomeDude: Or the mandatory support for per-vertex coordinate fog.
MostAwesomeDude: Either one, really, since the internal Mesa interface is the same for both.
MostAwesomeDude: I'm just having a headache trying to get the VAP, VPS, RS, and FP to all agree on fog.
marcheu: I think you have pretty wide flexibility in the impelmentation
marcheu: what equation do you use ?
MostAwesomeDude: marcheu: Right now we're using dedicated HW fog.
MostAwesomeDude: It's at the VERY end of the pipeline.
MostAwesomeDude: And we don't consume it with the FP, because Mesa's default fragprogs don't consume fog.
marcheu: uh, isn't hw fog distance based ?
MostAwesomeDude: marcheu: Ish.
marcheu: uh, so per vertex fog isn't, and how do both stick together ?
MostAwesomeDude: We can either do HW fog based on distance, or based on the FP's depth write.
MostAwesomeDude: If you specify a fog coord, then it's treated as fog depth, available as fragment.fogcoord to FP, and the FP is ultimately responsible for making the fog happen.
MostAwesomeDude: ...But in order to let HW do its thing, we're just always using the HW fog.
MostAwesomeDude: Since the HW can do linear, exp, and exp2 fog, we don't have to do FP fog.
MostAwesomeDude: Boy, I almost sound like a real programmer!
marcheu: I still don't understand. your hw fog is based on the depth coord, and you should be using the fog coord
marcheu: it seems that's not going to stick together
MostAwesomeDude: marcheu: We have a register, FG_DEPTH_SRC, which lets us either use the actual depth, or FP depth output, as the fog coord.
marcheu: ah ok
MostAwesomeDude: The problem is currently in getting the fog coord up into the RS, and then making it available to the FP.
marcheu: so it's more like you're having trouble routing the fragment attributes
MostAwesomeDude: Bingo.
MostAwesomeDude: Because Mesa isn't obligated to give us an FP with fog handling.
MostAwesomeDude: But fog might still be enabled, so we still have to route the fog coords.
MostAwesomeDude: And if it's depth-based, then the coords will magically show up in the fog HW. If it's fragment-based, then FP has to do an explicit depth write.
marcheu: ah that's pretty annoying
MostAwesomeDude: Oh yeah.
MostAwesomeDude: We're going to have to pre-parse all FPs to make sure at least one depth write happens...
MostAwesomeDude: But really, I enjoy the FP. It's a reasonably sensible chip.
MostAwesomeDude: It's the RS and VAP that I don't understand. At all.
marcheu: yeah see what happened to glisse after he touched it
MostAwesomeDude: XD!
damentz: hey, when are we switching to the new microcode?
MostAwesomeDude: damentz: ?
marcheu: damentz: did those ever fix something for you ?
damentz: there's a git branch called mesa/broken/drm
airlied: damentz: the drm tree switched already.
damentz: airlied: oh
damentz: url = git://anongit.freedesktop.org/git/mesa/drm
damentz: thats the right one?
damentz: i'm not sure if it's installing right though
damentz: the readme has all these weird things it wants me to do
damentz: i just do ./autogen.sh --prefix=/usr
damentz: should be fine on debian sid right?
airlied: damentz: you need to manually install the kernel modules
damentz: oh
damentz: how?
damentz: i'm doing make; make install
damentz: shouldn't that do it?
damentz: or am i missing something
airlied: make install might do it, but on some distros it doesn't.
airlied: maybe make install in the linux-core directory
MostAwesomeDude: damentz: You'll have to go into linux-core and "make && make install" there too.
damentz: ohhh
damentz: ok i'm doing that
damentz: it's taking way longer this time
damentz: err, oh bad idea
damentz: the laptop is on my laptop
damentz: well, there goes my gonads
damentz: stupid overheating laptop
damentz: laptop is on my lap*
damentz: awesome, let me test them now
damentz: brb guys
MostAwesomeDude: airlied: BRB, gotta change locations.
damentz: i've been running the new microcode for a while
damentz: i tried playing a few games
damentz: seems to run fine
damentz: games render properly
damentz: tried warsow and nexuiz
Flice: actually, fglrx is not really so crappy as I thought. in the newest version, they have introduced a working(!) vrefresh configuration, which eliminated my video tearing issue, when using the "gl2" driver in mplayer. of course, no other players or video drivers work :)
Nyle: hi
Nyle: I get an error about not having man in when trying to make radeonhd
Nyle: make[2]: *** No rule to make target `radeonhd.@DRIVER_MAN_SUFFIX@', needed by `all-am'. Stop.
rx__: wrong channel.. try #radeonhd
Nyle: no
Nyle: I asked here before they said i can ask questions about radeonhd in here too
Nyle: they said its the same thing if i ask here or there
rx__: you were misinformed
moondrake: Nyle: well, depends on how they formulated it. radeon does have the same bug though in this particular case
moondrake: but if you are using radeonhd, you should join that channel nonetheless
Nyle: rx__, ok sorry i didn't know right
Nyle: ok will do
moondrake: anyway, it doesn't matter much. it fails on building the man page
Nyle: but they also said that is better to be using radeon instead of radeonhd
moondrake: which you probably won't need
moondrake: Nyle: haha, they said that?
Nyle: moondrake, can we make it ignore man
Nyle: moondrake, yes one of the jr. devs here said
Nyle: the awesome dude
moondrake: ah, someone here. I thought someone in #radeonhd
Nyle: moondrake, I just noticed your nickname
moondrake: anyway. if you want to use radeon instead (which i agree, is a quite bit more useful atm)
Nyle: I have a drake tattoo on my left calf btw :D
Nyle: moondrake, I'm trying to work compiz fusion under radeon/ x1900xt
Nyle: debian sid
moondrake: then checkout the ati driver instead of radeonhd
Nyle: ok
Nyle: ati it says provides the radeon driver
moondrake: Nyle: compiz should work with the radeon driver, but not with radeonhd
Nyle: so not using sid radeon driver but one from git and i should get 3d?
Nyle: moondrake, radeon driver on r580 chip?
moondrake: yes, the one from git, plus some other things
moondrake: it is not going to be totally stable however
Nyle: like xorg and mesa and drm
Nyle: i don't care stablety i want to find bugs maybe help where i can and get this driver to be gooder
moondrake: i think it will work on r580, but not completely sure. it does work on my x1400 though
moondrake: Nyle: yes that should be enough i think
Nyle: ok
Nyle: my net is like 12kb/s so it takes long time
Nyle: :(
moondrake: heh :)
rx__: should work on x1900xt
rx__: i think airlied has a x1900 variant
Nyle: xtx?
rx__: possibly
rx__: i forget :)
Nyle: only xt and xtx afaik, 256 and 512 models
Nyle: :)
moondrake: off for lunch
Nyle: enjoy, midnight here
Nyle: :)
rx__: could've been x1950
Nyle: oh that one
rx__: x1950xtx