matteo: why is the development stopped for so much time?
libvde: matteo: check out the people trees
libvde: i hope to be adding the CP work and the quick accel conversion today
libvde: matteo: all of us are working on rather major additions, and until they are somewhat decent, they will not make it into the main tree
libvde: s/tree/repository/
matteo: libv: what about the DRM support
libvde: matteo: so go to gitweb.freedesktop.org and search for radeonhd
libvde: matteo: emmes his tree
matteo: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd
matteo: i'm here
emmes: that's the main tree
emmes: until it's in merge state, it will only be in git://people.freedesktop.org/~mhopf/radeonhd as indicated in my status mail on the radeonhd ml
udovdh: hmmm... interesting
udovdh: really would like new features in the driver for rv630 :-)
emmes: udovdh: currently there is no DRM/DRI support for r6xx yet (rs690 is in fact r3xx...)
emmes: but that's somehow next on the agenda
udovdh: of course.. :-)
udovdh: (im)patiently waiting...
matteo: is r600 a radeon X2XXX and 3XXX?
egbert: matteo: yes.
egbert: accel wise
matteo: what does the DRM support? accelates memcpy?
emmes: prerequisite for DRI.
libvde: matteo: busmaster dma, yes
libvde: matteo: pretty much the only thing we will not be able to offer with direct CP usage (we will be offering render compositing and textured video without the DRM present too)
egbert: matteo: interrupt handling
matteo: is DRM support possible?
matteo: have you all specs?
matteo: the DRM module is always here I see
egbert: for r6xx not yet.
libvde: matteo: right, but this is not always the case for all operating systems, all kernel version or all versions of all distributions that our driver builds for
matteo: libv: doesn't you develop ever on a latest kernel, latest xorg and latest driver?
libvde: matteo: no, this would mean that only those who have the latest kernel and the latest xorg can use our driver
libvde: matteo: everybody with a semi-recent system should be able to build and use our driver
matteo: libv: you can add support for DRM, then distro makers will package them
matteo: from time to time the kernel synces the DRM tree
matteo: and in some future version it will work in new installations
matteo: or after an upgrade
libvde: matteo: the radeon drm only very recently learned about rs6xx and r5xx
matteo: sn't it?
matteo: i know
matteo: I also see that the r300 development is going very fast
Honk: is there any reason why my new screen would turn black with radeonhd on resolutions greater than 1280x1024? =)
egbert: Honk: is this a digital connector?
Honk: yepp
Honk: my old crt worked fine with a vga connection
egbert: Honk: ah, ok. and the dvi-d works with resolutions < 1280x1024?
Honk: yeah
Honk: well.. with 1280x1024 at least, didnt check with lower resolutions :P
egbert: ok, can you mail a verbose log to radeonhd?
egbert: Honk: ok.
Honk: yeah, will do
egbert: Honk: ok, thanks.
egbert: Honk: we have several of these reports. so far we were unable to reproduce them ourselves.
Honk: anything else I should include?
egbert: not for now. be sure to create a verbose 7 log, though.
Honk: yeh :)
Honk: I guess I should update radeonhd before posting :P
egbert: Honk: this might be a good idea :)
Honk: good.. no change ;)
egbert: Honk: not good, but whatever...
Honk: :P
egbert: Honk: maybe you can send me your bios, too (in private). or should i have this already? :p
Honk: xrandr -s 1280x960 <-- that's dead as well btw
egbert: Honk: this is a good hint. maybe we are able to see a pattern.
Honk: mailing the xorg logfile any time now ;)
Honk: to radeonhd@opensuse.org, right?
egbert: Honk: thanks :)
egbert: Honk: yes.
libv: egbert: could it be the bug i fixed on lvtma recently?
libv: i think i pushed this straight upstream
egbert: libv: Honk pulled the latest sources.
egbert: libv: i was hoping that it somehow was related. but no...
egbert: libv: still need to check the log, though.
Honk: kk, sent :P
Honk: omg, it worked =)
egbert: Honk: i got your message, yes.
Honk:
Honk:
Honk: I see :P
egbert: Honk: right ;)
Honk: scrollback buffer ftw
Honk: sent =)
egbert: Honk: still around?
egbert: Honk: when you set the 1280x1024 mode what does xrandr -q say? ie, what's the vrefresh?
martel80: hi
martel80: can someone please help me with TV viewing in Linux with a HD 3870 card?
egbert: martel80: tv out isn't supported yet.
egbert: martel80: most bits are there but things still need to be hooked up properly.
martel80: I need only a TV application that would work with radeonhd
martel80: something like tvtime
egbert: ah, ok. this should just work.
martel80: but tvtime requires overlay, doesn't it?
egbert: depends. not necessarily.
martel80: i haven't managed to get TV working on the vesa driver
egbert: v4l has different modes.
egbert: but i have to admit, this is something i've never tried.
martel80: when I tried tvtime with vesa driver, it always gave me a black window and after several tvtime restarts, it eventually nuked down whole OS
martel80: I tried setting various output modes but to no success
egbert: so it worked on principle without overlays. but something wasn't set up right.
martel80: I thought someone new a TV application that could render the captured video by standard X11 rendering
martel80: someone could know...
egbert: you are trying to use a tv card, right?
martel80: yes
martel80: which would work without HW overlay, just using plain X11 bitmap rendering
martel80: my card can capture directly to RGB 24/32 so there should be no problem with conversion
martel80: I checked the modules and it seems all the TV card drivers are properly set up
martel80: I even managed mythTV to play something from the tuner
martel80: unfortunately, it stopped working after restart. and the whole mythTV is a bit of overkill anyway
egbert: martel80: i used to use xawtv for a while. it's rather cumbersome to operate but you can select how the tv picture gets drawn to the screen.
martel80: i'm getting it through apt
martel80: WARNING: couldn't find framebuffer base address, try manual
martel80: configuration ("v4l-conf -a
egbert: ah, ok.
martel80: where do I find my framebuffer?
egbert: let me check something...
martel80: there's also other warning - WARNING: No DGA support available for this display.
egbert: right. we don't support dga.
egbert: martel80: still around?
martel80: yes
egbert: martel80: ok, can you try a patch?
egbert: --- a/src/rhd_driver.c
egbert: +++ b/src/rhd_driver.c
egbert: @@ -1051,6 +1051,8 @@ RHDScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
egbert:
egbert: xf86DPMSInit(pScreen, (DPMSSetProcPtr)RHDDisplayPowerManagementSet,0);
egbert:
egbert: + pScrn->memPhysBase = rhdPtr->FbPhysAddress + rhdPtr->FbScanoutStart;
egbert: +
egbert: /* Wrap the current CloseScreen function */
egbert: rhdPtr->CloseScreen = pScreen->CloseScreen;
egbert: pScreen->CloseScreen = RHDCloseScreen;
martel80: hey, I'm not that advanced to recompile stuff :(
egbert: hrm.
martel80: the framebuffer the xawtv is referring to is the framebuffer of the graphics card or the TV tuner card?
egbert: graphics card.
egbert: the tv card doesn't have a framebuffer.
martel80: i thought it had a memory-mapped output buffer...
egbert: martel80: what does lspci -v tell you for the tv card?
martel80: 05:02.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev d0)
martel80: Subsystem: ASUSTeK Computer Inc. P7131 Dual
martel80: Flags: bus master, medium devsel, latency 64, IRQ 18
martel80: Memory at febff800 (32-bit, non-prefetchable) [size=2K]
martel80: Capabilities: [40] Power Management version 2
martel80: so it has a framebuffer (2k):)
martel80: I tried xawtv -remote and didn't get any warnings
egbert: so did it work?
martel80: well, I cannot find out how to add a TV channel. Where do I put a channel number?
martel80: in xawtv
egbert: hrm. long time since i've used it...
martel80: is station ID the TV channel number?
martel80: well, I guess I'm going to read some xawtv tutorial, so thank for your help so far :)
egbert: martel80: :)
martel80: the GUI is crude, man :)
egbert: martel80: didn't i promise that? :p
martel80: super, I managed to get visual reception, now get audio and all will be fine :)
egbert: martel80: :)
martel80: anytime I change some setting, i get this:
martel80: *** glibc detected *** /usr/bin/xawtv: double free or corruption (!prev): 0x00000000007b4850 ***
martel80: ======= Backtrace: =========
martel80: ...
martel80: :(
tulcod: martel80: please don't post in IRC. use rafb.net/paste.
tulcod: :)
martel80: sorry
Honk: egbert: sorry, booted windows to play some wow =)
libv: tigerchen: i tracked the restore issue with the external display now
libv: tigerchen: crtc vs pll ownership needs to be restored when the pll is restored
libv: not when the crtc is restored
egbert: Honk: i wanted you to add mode lines with different clock frequencies.
egbert: Honk: use a mode line which works and see if a pll frequency of a mode line which doesn't work give you a blank screeen.
egbert: Honk: but i should call it a day today. let's postpone this to another day.
g-zu: I just wanted to say a big thanks for today's commit to the main tree
g-zu: the one saying that fixes some issues on rs690
g-zu: it's a very welcome update for my laptop... now I can even watch fullscreen movies using x11 output
g-zu: most stuff works much faster than before, so thanks again
g-zu: I'm still a bit sad that it only supports native resolution
libv: g-zu: egbert will fix that one soon as well
libv: g-zu: there's a whole bunch of code to that end lined up
g-zu: I saw he has a scaler branch... I supposed it's for that... IIRC that's what's missing
libv: g-zu: exactly
g-zu: anyway good job people... I use this driver since it started working on my machine
libv: g-zu: nice to hear that you're so happy with it :)
g-zu: and I'm very happy with the progress it's making
libv: :)
g-zu: I didn't expect to see so many ppl here though, I read the logs every now and then and only a few have said anything
libv: right, the level of talk seems to very much depend on the amount of code being pushed around, and whether or not it breaks stuff :p
g-zu: I also tried the drm code... it works but seems kind of slow... as in I expected a higher framerate in gears from it
g-zu: but I guess that will go up soon, too
g-zu: will the drm stuff only get integrated once it works with XAA/EXA ?
libv: i am currently trying to come up with a clean fix for a bug that has been haunting us for many months now
libv: but i have code to use the command processor even without the drm here, and it works nicely
libv: it already has our current exa/xaa code ported over (quickly)
libv: mhopf and i will stick our heads together tomorrow on how to make the cp interface general for the direct cp usage versus drm
g-zu: wow, nice
g-zu: I don't really know this stuff but won't that make integration with mesa harder for you guys? as I understood it mesa depends on libdrm
libv: sure, we will not have mesa when we do not have drm
libv: but we will have hw accelerated compositing and textured video
libv: on top of the advantage of having only a single copy for all the acceleration code
g-zu: sounds good... I'm looking forward for textured video... and composition too, will it be complete the compositing support without mesa?
libv: all it will not have is fast up/download through the dma engine, as this requires a working GART
libv: it will have to make do with memcpy
libv: when we do not have drm, that is :)
g-zu: that's acceptable for now... I've been curious for some time what was made on this side in kde4
libv: well, mhopf wrote up the drm support, so these things will happen simultaneously
libv: but this will require that you have a recent drm installed and such
g-zu: that's not a problem...
libv: in case you do not have a recent drm installed, things will just be slower, that's all :)
g-zu: I don't mind compiling some stuff
libv: well, it saves a bit of a headache for quite a few people
g-zu: yeah... I know.... however for a recent drm I don't even have to bother with the repository and everything, gentoo has this on the x11 overlay... only thing I have to do is build this driver(it's not in the overlay)
libv: plus, it is a good proof of concept of how we will go about bootstrapping an r6xx drm, cp will be working in fb first, and then people can all go off and implement everything that depends on just the cp working
g-zu: wow... you really thought this trough a lot
g-zu: nice work, thanks for your input libv
libv: you're welcome :)
Honk: egbert: uhh.. all modes that work are 70 or more hz, those that dont are ~60hz
Honk: but 1280x1024 works in 60hz as well.. *shrug*
MistaPink: hi
MistaPink: I've downloaded version 1.2.1 and tried to use ./autogen.sh, but this script is not in the tar-archive
MistaPink: where can I find it?
MistaPink: or is there any other workaround?
g-zu: you don't need to ran ./autogen.sh for tar... just ./configure
g-zu: ./autogen.sh is only for git repository
g-zu: use ./configure --prefix=/usr && make && make install
MistaPink: erm, ok thx
MistaPink: and what do I have to enter in the xorg.conf? I'd guess radeonhd
MistaPink: ok it works, thx for your help
victamower: hi
victamower: with the fglrx drivers in Hardy running on my Thinkpad T60 with Mobility X1400, I get horizontal "jitters" on the Dell 2407 monitor I have attached to the VGA port
victamower: any ideas?
victamower: doesn't happen with the fglrx drivers in Gutsy