kajik: hi i cant get radeonhd to work on my thinkpad t60 with x1400
kajik: i always get fatal server
kajik: fatal server error, no screens found
kajik: i think my xorg.org is messed up by fglrx
dmb: you can see mine if you want, which works
kajik: woul db enice
kajik: can you paste it somewhere?
kajik: i pasted mine here http://ubuntuusers.de/paste/123661/
Sadako: kajik: you have no "Device" section with radeonhd, just two with fglrx
dmb: i have an x1400
kajik: i know, izts the working fglrx config
udovdh: a few updates I see
Tigerchen: yes, had nothing to do last night
udovdh: minor but still nice to see
udovdh: no effects for rv630 I presume?
Tigerchen: i think so, since i dont have a rv630
udovdh: just hoping for progress during the easter weekend ;-)
Tigerchen: hope dies last ^^
Tigerchen: but there might be something, since they also work at 0200 in the morning ^^
kajik: hi there, i tried it with your xorg bzut still the same problem
kajik: you can find xorg.log here http://ubuntuusers.de/paste/123757/
kajik: and this is my actual xorg.conf, http://ubuntuusers.de/paste/123774/ i have no clue why it is complaining about an "Undefined Screen "aticonfig-Screen""
libv: kajik: you have two serverlayouts apparently
kajik: so maybe i should try to boot with an single head fglrx layout and shold try to change to radeonhd after that
libv: no, just get rid of the first serverlayout section
libv: use a text editor
kajik: thanx, i will try it
udovdh: man vi
Tigerchen: libv, hey
Arrow: Hi all
kajik: ok, thanx it works now, i just didnt recognize the first layout section.
libv: hi Tigerchen
Tigerchen: libv: want to work?
libv: Tigerchen: sadly i am working :( apparently users would like to be warned when the accidentally hit crtl-alt-backspace
libv: making X not die immediately and warn first is easy enough... But... X was never used to not dying immediately, so the same event gets called three times
Tigerchen: if i hit ctrl+alt+bs i want the server just to die (and that quikcly)
libv: Tigerchen: yeah, imho it is bullshit too...
Tigerchen: boss says so, you code it so?
libv: Tigerchen: but managers will be managers
libv: (and they don't admit that it was them that hit ctrl-alt-backspace)
libv: oh, this has been an ongoing discussion for years
dmb: oh, fsck that
libv: if X wasn't such a crufty mess (and getting cruftier, with people replacing things all the time instead of fixing up/cleaning up things) i would've been done hours ago
dmb: the whole point of using crtl-alt-backspace is to kill the server
libv: i get the same event three times... the two later times never used to happen as X by that time would've been taken down already
libv: dmb: indeed
Tigerchen: libv: please say that this "are you sure" will come into main Xorg, but only in susi
dmb: xorg is a huge mess
dmb: someone should just write a nice lite x server from scratch
libv: dmb: press it once, machine will beep loudly, press it again within 2s and X will go down, press it again more than 2s later and machine will beep again
libv: dmb: will come with an option of course, default off, but apparently opensuse will set this option
dmb: thats not that bad
libv: but then it's a managers decision
dmb: annoying, but not that bad
libv: dmb: sure, i don't want this thing at all
libv: i ctrl-alt-bs my xservers all the time
libv: it's going to be bad enough that every new install will come with this enabled :(
libv: will be a hell of a racket in here
dmb: yes, same
dmb: especially if it uses the system speaker
dmb: which is loud and obnoxious on most computers
libv: it has to use the speaker
libv: this is the easiest and most painful warning
libv: i don't want an xlib box to pop up, that'd be useless
libv: i don't want any drawing to take place, as that might be the reason why the server needs to go down
libv: will be fun though
libv: now said managers can no longer deny being stupid enough to press ctrl-alt-bs
libv: half the hallway will hear it :p
Tigerchen: hmm, last two boxes i set up, i threw away the 1¢-size-beeper
libv: Tigerchen: not that smart imho... take graphics cards for instance, their bioses often come with beeper code in there
libv: Tigerchen: big ones which need external power connectors often beep to alert that this connector is not wired up
libv: Tigerchen: but even unichrome vga bioses come with beeper code in them
Tigerchen: 1 box had no discrete graphics
libv: not sure i ever heard them use it
Tigerchen: the other uses a passive-cooled 8600gt or something
libv: but there's an S3 card egbert uses in this office for testing non-primary that beeps when there is no monitor attached to it
dmb: guess what the first module in my modules.blacklist file is?
libv: dmb: i guess many opensuse users will soon do something like that or what tigerchen did too :)
libv: but i will make sure that there is a proper comment in the default xorg.conf
dmb: is that going into the xorg branch?
dmb: or just suse?
libv: i'll probably attach it to the bugzilla, i am sure it will be outright rejected by some.
libv: but then, some part of me knows that those will end up doing something similar at one point anyway
libv: it's how x.org works :)
airlied: libv: why don't you just set DontZap by default and let GNOME handle the C-A-B?
libv: airlied: this is what managers decided is the way to go.
libv: airlied: i can't wait until they turn it off themselves because they alert everyone with their beeping :)
ajax: we had a hack in our buildsystem client for a while that, whenever someone used --turbo, would send email to the guy who wrote the client.
dmb: lol wtf
ajax: i propose a similar hack here, but with the recipient being the company-wide mailing list.
airlied: libv: managers shouldn't get to decide policy, they are meant to define results :), I suggest new managers..
dmb: programmer is always the worker, manager is always the boss
dmb: you usually don't have a choice
libv: airlied: well, currently i'm applying "be careful what you ask for, or you might just get it". They will get laughed at themselves now, and there are a lot of users who will flame about this stupid beeping
airlied: dmb: you need to find a new job :)
libv: the whining has gone on long enough, and i think that even i, in the short history i have at this company, have spent more time arguing than i eventually will have spent implementing
airlied: dmb: I've never had managers direct my implementations..
dmb: airlied: at least in the US
libv: airlied: not even before you joined redhat?
airlied: dmb: unless they were technical managers and were helping with the implementation
dmb: yeh, its quite corrupt here
airlied: libv: rarely, I had free reign to design gaming machine how I liked..
airlied: libv: and bluetooth stuff, was follow the spec make it work directive
libv: well, this is the first real concession i make here, but it is the most acceptable solution, and one that is disabled per default, but set to on in the next opensuse alpha, and i am sure that it will go away again soon now
libv: and this will be the end of the bickering
dmb: my only issue with suse is the package management, its takes so long when it comes to installing a package, it seems to run the reconfigure scripts on things that don't effect the package every time
dmb: i'm sure that will be fixed in future versions
libv: i haven't personally made any concessions to any manager with respect to radeonhd, and i intend to keep it that way, or even further extend it
libv: dmb: coming from debian, package management is absolutely horrible here :)
libv: dmb: it's just a pain getting anything installed
dmb: yeh, i'm a debian person :P
dmb: indeed, i have to use suse enterprise server, and its very annoying
libv: i'm not sure how it is on other rpm distributions, but sometimes i really do miss apt
Death_Syn: libv: I used to use apt-get in OpenSuSE 10
dmb: i think redhat has yum, don't know what that is like
marcheu: yeah I have never made concessions to managers in my driver writing activities either :)
libv: marcheu: :)
Death_Syn: but I think the repositories are disappearing that support it
libv: marcheu: are promotors also pointy haired btw?
marcheu: libv: promotors ? of ?
Death_Syn: libv: might be a dilbert reference
Obscene_CNN: uses gentoo which has portage/emerge which is very nice
libv: marcheu: don't you have a promotor for doctoral and postdoctoral research?
marcheu: Death_Syn: there are no propotors in dilbert that I know of. and I've read them all :)
libv: Death_Syn: my bedtime reading the last few days was dogberts top secret management handbook
dmb: Obscene_CNN: and slow :D
marcheu: libv: ah, well it depends on the persons. mine surely left me laaarge margins and never interfered with the tech stuff
dmb: face it: there is an issue with every package manager
Death_Syn: marcheu: ahh
Death_Syn: what's wrong with apt?
libv: dmb: sure... it's something that will never ever be perfect
libv: dmb: and people find things they hate about every package manager... but still i felt rather better with apt than with whatever tool there is for rpm that i used in this millenium
ajax: apt-rpm works pretty okay-ish, i'm told.
ajax: enough so that people who hate yum but use fedora typically use apt.
glisse: package system is like windows once you get used to it you don't want to change
glisse: simple story of computer
dmb: libv: yes, making package for debian is also quite fun :D
libv: glisse: indeed, and you work around or try to ignore the ugly bits as best as you can eventually
libv: dmb: xf86-video-unichrome has a debian/ directory :)
dmb: eww, i hate upstream debian directories!
libv: dmb: used to work both against debian and ubuntu... was not too trivial to set up, but used to work quite well
libv: dmb: well... ubuntu shipped a -unichrome that didn't even load :)
libv: they renamed the binary, but they didn't rename the module loader hook
libv: dmb: i've been told that something similar with spec files could be possible
libv: dmb: but it is a pain to maintain though
dmb: "AMD Releases Production Microcode For All Radeon GPUs!!"
marcheu: you could get them for a couple of years from the windows driver...
marcheu: these could never bring anything that I knew..
dmb: marcheu: well, this is legal
marcheu: better would be the microcode documentation
dmb: i doubt we could touch the ones in the windows version
marcheu: well, my version was legal too
the-me: is there any possiblity, that I can see all branches of the git repo?
marcheu: I actually almost commited it at some point :)
the-me: or are they very private? :)
marcheu: yeah, releasing microcode documentation, now that would be a funny thing. you could optimize out by creating your own packets
marcheu: although I suspect only type3 packets use it, but what do I know...
dmb: marcheu: shouldn't they release an assembler and the asm code for the microcode?
dmb: or am i thinking nonsense
marcheu: dmb: I think it's hand-assembled, but at least docs
dmb: marcheu: what do you mean hand assembled, you mean they wrote it directly in hex?
dmb: thats horrible :D
marcheu: the format seems pretty simple, they might have a simple tool
marcheu: nothin I'd call an assembler :)
dmb: i wonder if that dump is considered gpl compatible without the docs
dmb: michaellarabel: any updates on ut3 yet?
michaellarabel: dmb: Unfortunately not... Though there is increased speculation now that STEAM may be coming to Linux.
michaellarabel: Speaking of which, it's the 19th today... exactly 5 months ago UT3 was released :(
dmb: that could be very interesting... steam on linux
dmb: i always heard that they had a secret linux client port, they just never released it, it would be interesting if it actually did come out
michaellarabel: If you didn't hear, UT3 is now on STEAM
dmb: it is?
michaellarabel: The announcement came out earlier this week
dmb: i must really be out of the loop
dmb: libv: do you know if there is a way to change the VGA mode in linux?
dmb: on the fly?
dmb: (vga textmode)
libv: dmb: what do you mean with change?
libv: dmb: set a different resolution?
dmb: well, i was told there were different vga textmodes provided by the vga specification
libv: dmb: this is not feasible on any hardware that can still be used today
libv: dmb: most vga compatible hw should not be modeset through vga but through their native drivers or through vesa
lucas__: hey, I have a RS690 chip in my computer am I am missing the TV-Out feature for it
lucas__: so I thought if I could implement it in radeonhd]
dmb: libv: is there a program to manipulate vesa modes?
lucas__: is someone wirking on tv-out?
libv: dmb: vbetool or something
libv: lucas__: there is some preliminary code for this in radeonhd
libv: lucas__: but it is not really useful yet, i am not sure why
libv: either a lack of time or a lack of information or a combination of both
michaellarabel: libv: egbert mentioned that all of the components should be in there for tv-out, but they just need to be connected and then tested.
libv: michaellarabel: ok... but this was before he sunk his teeth in rv620/635
libv: so this was quite some time and some code ago :)
libv: not sure when he will be able to pick this up again
michaellarabel: Actually he mentioned that (connecting & testing) to me just last week before going on holiday
lucas__: although I have no experience in drivers programming, I would like to get into the project
libv: ah, ok :)
libv: lucas__: i think part of the code lives in rhd_dac.c
libv: lucas__: but you can find some commit messages in our git log mentioning tv
lucas__: I'll search for it
libv: lucas__: 47298a34 and older
lucas__: libv, I did a search for tv on repository and found some entries
libv: lucas__: run gitk, feed the part of the sha-id i gave you in the sha-id box
lucas__: oh, thanks
lucas__: I am new to git
libv: lucas__: :)
lucas__: libv, have an advice on where to start?
libv: lucas__: start from the connector, check whether the connector is properly defined, then check whether the output is accordingly initialised and enabled
lucas__: libv, ok
lucas__: can I burn my motherboard if I do something wrong?
dmb: Tigerchen: have you ever got radeonhd
dmb: i meant have you ever got radeonfb working
libv: right... done playing silly buggers for today :)