rainbyte: hi
joss193: chithead, something like this http://www.linux.com/feature/154368
joss193: but for second X not virtual machine is needed
nha: osiris_: any news about that lockup?
joss193: anyone. knows how to model this vmgl to work without virtual machines, on different displays?
joss193: http://www.linux.com/feature/154368
Honk: joss193: are you sure it doesnt just work? ;P
joss193: Honk, what does not just work?
joss193: ah in localhost the same method, using guest as DISPLAY=:1 Xorg?
joss193: i think not, tried with chromium though..i could try, but i doubt
Honk: yeah
Honk: they're even talking about ssh forwarding on the webpage
Honk: I dont see why you couldnt do that with localhost as target
joss193: Honk, hmm, can you tell my what is that fixed font? seems i to not have it lying around
joss193: Xvnc wants it, i have built-in-fonts i think
Honk: did you do the -fp thingy?
joss193: Honk: then the server and viewer will be the same target
joss193: Honk, yeah, but still says missing fixed font
Honk: *shrug*
joss193: Honk, i think that is easier to fix then mu Xcliplist error previous problem, with chromium still, but i have the font tree still, weird it wont start
Honk: c&p the error in google
joss193: https://issues.foresightlinux.org/browse/FL-1671;jsessionid=B9E2DD60443FD5F202D7A9C74329F48D?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel
joss193: same as here
joss193: Honk, i think this is connected with permissions and auth somehow, it also tries 7100 port for fonts
Honk: I dont think so ;P
joss193: i have -audit 0 in gdm for current session
joss193: i think that means no auth at all no MAGIC cookies
Honk: doesnt matter ;P
Honk: the -fp thingy is just plain wrong :]
Honk: unix/:7100 is not where you want xvnc to look =)
Honk: ah yesh
Honk: try -co /usr/share/X11/rgb
Honk: if you really have the same error, that'll fix one part of the problem at least ;P
Honk: and if you want a dirty fix.. just symlink the fonts directory =)
joss193: Honk, thats allready fixed
joss193: Honk, did that several times, just says font path not found ignoring
Honk: well, do the paths xvnc is trying to open exist? ;P
joss193: Honk> yeh heh sure
joss193: some weirdo error again
Honk: then post your error message
Honk: :P
joss193: http://nopaste.com/p/a0jtJMnSn
Honk: rotflmao
Honk: you've gotta be kidding
joss193: eh?
Honk:
Honk: ...
joss193: certainly. for sure
Honk: I wasnt asking if you THINK that they exist, I was asking whether you actually checked
Honk: and you didnt, cuz that path sure as hell doesnt exist
joss193: HONK, 10 times
Honk: how?
Honk: ls -copyandpaste the path from the error-
Honk: like that?
joss193: want an ls line?
Honk: yes, please
Honk: ls -ld ;)
joss193: ls -ld /usr/share/fonts/X11
joss193: drwxr-xr-x 8 root root 4096 2008-10-30 09:32 /usr/share/fonts/X11
joss193: weirdo isn't it
Honk: yeah, your system is all messed up ;P
joss193: yestirday made a clean install
joss193: >D
Honk: *nod*
Honk: messed up =D
joss193: tired of those, debian is really bit cheese
joss193: its like a joke really
joss193: need to do the system all from scratch like gentoo does it i think
Honk: anyway.. no clue what's wrong ;P
Honk: nah, the system is ok - i wasnt serious ;)
Honk: then again
Honk: you didnt google, did you?
joss193: actually i little did
Honk: http://ubuntuforums.org/archive/index.php/t-80199.html <-- first hit
joss193: heckheckheck, dos not work
Honk:
joss193: Absolutely the same
Honk: well, the cmdline would be different ;)
joss193: Xvnc -fp /usr/share/X11/fonts/ :4
joss193: Font directory '/usr/share/X11/fonts/' not found - ignoring
joss193: path exists and copied that vnc.conf file to etc
joss193: also can not find an option for -confg to point that for sure
joss193: to be sure, that Xvnc parses it, but yeah i have ubuntu 8.10
Honk:
Honk:
Honk: ...
Honk: geesh
Honk: and dont use some weird .conf file, use -fp
joss: Honk: think i need to reinstall the system again, next time i will do a backup also..
laj:
rettub: hi, I've big problem with 3D, ati radeon 9300pro (rv280), lenny kernel 2.6.28, amd xp2600. If I start eg. eracer xorg will have a load of 95%. No more keyboerd, If I kill9 it via ssh it will become a zombi with the same load. any hints?
rettub: glxgears says eg.:802 frames in 5.0 seconds = 160.398 FPS
rettub: If you like to see my configs, logs: http://paste.debian.net/28896
adamk: rettub: Have you tried setting a slower AGP rate?
rettub: adamk: slower as '4' - no, I have to AGPMODE ' 4' in my config cause '8' will freeze
rettub: should I try '2' ?
adamk: Try 2... There's even a way to force it to PCI mode.
rettub: thx I will ...
rettub: adamk: freeze
rettub: etracer CPU 96%
adamk: Since you are already have problems you know about with your AGP chipset, I'd really be inclined to think that's where this problem lies, too, but I could be wrong.
rettub: adamk: there are agpmode -1,1 too I'll try that ...
rettub: adamk: befor I had etch installed and I had no such problem, even without setting agpmode to '4'
adamk: Different kernel versions, different AGP driver versions, probably
rettub: agmode 1: complete freeze :(
rettub: adamk: do you have an idea how to test the AGP chipset?
adamk: rettub: I do not, sorry.
rettub: adamk: hm - anyway thx!
la_boheme: short of compiling everything myself, is there a binary linux distro out there that makes having all the latest drm, xorg, etc relatively painless ? i was thinking maybe debian lenny with unstable/experimental repos
kcodyjr: la_boheme, no. the closest you can get is gentoo; perhaps there are other source based distros as well, but i know gentoo to have appropriate overlays for bleeding edge X
kcodyjr: that is the nature of the bleeding edge; git sources.
kcodyjr: if we call that the "tip of the knife" then you could get "the handle of the knife" with fedora core, but that's based on whoever decides it's prudent to generate new packages
la_boheme: thanks kcodyjr. let me rephrase then - which of the binary distros has the closest match to what i want ? so that things are relatively new, frequently updated, and i don't have to compile anything
kcodyjr: latest fedora core, but it's not updated all that frequently.
kcodyjr: repeat: if you want frequent updates to the very latest, the best you can hope for is to -automate- compiling from git.
kcodyjr: if you're not willing to compile, then honestly this stuff isn't ready for you
la_boheme: heh. well i only compile my own stuff, not other people's. life is too short :)
kcodyjr: semi-technical/semi-endusers that don't want to risk their systems, usually do it with a chroot inside whatever their favorite distro is
kcodyjr: so, boot debian, use a gentoo chroot or whatever for the bleeding edge testing
kcodyjr: i can't argue that, but i am thus compelled to counsel patience.
kcodyjr: perhaps you ought to compile once and then write them a script to build daily snapshots into packages. ;)
kcodyjr: i'm sure such a script would be welcomed, especially if it actually works.
kcodyjr: i mean c'mon, it's not like -you- have to compile each line of C into ASM, after manually doing the C preprocessing line by line, comparing the frickin ifdef's one at a time... now that would suck ;)
kcodyjr: but scripting the build is reasonable for anyone that's interested enough to try bleeding edge code
kcodyjr: some would argue if you're not willing to "git pull ; ./configure ; make" at the command line, you shouldn't be playing at the bleeding edge
la_boheme: i hear your plaintive orisons, but alas i am not for turning. debian lenny/experimental it is
kcodyjr: huzzah. ;)
kcodyjr: i do know that fedora is more likely to get a package than debian, for whatever that's worth
kcodyjr: but we're talking, what, 1% odds versus 5% odds?
kcodyjr: love to chat but i have to go deal with a borked server. later all.
la_boheme: later squire
ConnorBehan: once I have the modesetting capable kernel, libdrm and DDX, is mesa the only thing I have to recompile?
ConnorBehan: if I want to use the modesetting radeon driver, I don't need the gallium mesa branch correct? there's another one I could use that's more similar to the stable mesa?
ConnorBehan: I need to know what is likely to have the best 3D performance:
ConnorBehan: using a stable radeon driver and a stable mesa?
ConnorBehan: using the modesetting radeon driver and the modesetting mesa?
ConnorBehan: using the modesetting radeon driver and the gallium mesa?
ConnorBehan: I know that I could suffer many crashes if I use radeon modeset=1
ConnorBehan: but what if I use all the modesetting capable stuff but I disable the modeset option for the driver?
spstarr: hullo bridgman
spstarr: bridgman: 5-10cm, locally 15cm snowstorm coming
bridgman: ConnorBehan; not sure if there is mesa code that works with kernel modesetting (and memory management) yet
bridgman: definitely being worked on but not sure if it's running yet
bridgman: gallium mesa is at very early stages, definitely not ready for use yet
bridgman: hi spstarr
ConnorBehan: bridgman: I'm getting this from http://tirdc.livejournal.com/23805.html
bridgman: seems like it snows all the time these days
spstarr: bridgman: im getting sick of it ;/
ConnorBehan: ideally I'd like a mesa package that can be as unstable as it wants when I use it with a radeon driver that has been inserted with modeset=1
ConnorBehan: but behaves more or less like mesa 7.2 when I use it with the modesetting capable radeon driver with modeset=0
ConnorBehan: you're saying the gallium-0.2-radeon will be very unstable whether or not I have modesetting on?
bridgman: I'm saying that current state of gallium mesa for radeon is that it can clear the screen and maybe draw a point (not sure about the point)
bridgman: it's *really* not ready for you to use yet, just to add code to ;)
bridgman: but it's pretty stable
bridgman: So what does it do right now? Well, to be honest: Nothing. But it's the point at where the groundwork should be (mostly) done and development can focus on actually implementing features.
bridgman: sorry, missed the quotation marks
ConnorBehan: are you referring to the gallium-0.2-radeon branch of git://anongit.freedesktop.org/~csimpson/mesa?
bridgman: there is a branch of mesa where all the work is being done to run over a memory manager; not sure if that code auto-switches depending on whether mm is present
bridgman: yeah, although AFAIK all that has been merged to mesa master now so you don't need to look at the branch any more
bridgman: MostAwesomeDude pushed his code into the "main" gallium-0.2 then gallium-0.2 was merged into mesa master
ConnorBehan: so if I start a console and type modprobe radeon modeset=1 and it loads...
ConnorBehan: is there any mesa installation that will allow me to then type startx and see X start normally...
bridgman: I think that would be touching the drm module, not mesa
bridgman: sorry, replied too soon
bridgman: X and mesa are pretty independent; starting X doesn't use mesa
ConnorBehan: ok but if I try running glxgears in X that will use mesa?
bridgman: yes it will
ConnorBehan: ok so loading radeon modeset=1 and starting X shouldn't be a problem for me
bridgman: just not sure what you will get running over kms today; might be HW accelerated, might be sw
bridgman: my guess is yes, although I don't know exactly how the boot manager loads the drm today
ConnorBehan: so if I do that a mesa that will allow me to see direct rendering: Yes and glxgears framerates comparable to what I see now might not exist?
bridgman: be careful about direct rendering; until a few months ago "direct rendering; yes" meant you had hardware acceleration, but these days you can have direct rendering with sw-only
bridgman: but yeah, what I don't know is whether there is a hardware accelerated mesa which runs over kms today
bridgman: AFAIK airlied was merging r100 and r200 into r300 as a prelude to finishing the mesa-over-memory-management work and getting mesa to run over a drm with kms and memory management enabled
ConnorBehan: besides the oh so not ready gallium one
bridgman: exactly; since the gallium work is "for the future" it's being built on all the newest stuff; dri2, kms, gem
bridgman: so it *will* work over a kms-enabled drm, it's just midway through development
bridgman: this is a question best asked about 12 hours from now when airlied isn't sleeping ;)
ConnorBehan: heh
ConnorBehan: so if I use that with a kms radeon driver, I'll be able to startx since X doesn't use mesa
ConnorBehan: but if I try running glxgears, that's when I might see just a point or something
bridgman: I think so, with a couple of caveats
bridgman: 1. I'm guessing that you can manually load drm; it definitely works with the Fedora boot manager but probably works outside that as well
ConnorBehan: yeah I can
bridgman: 2. running glxgears over the current gallium mesa code will probably blow up rather than drawing points; don't think glxgears actually uses points
ConnorBehan: oh ok
bridgman: MostAwesomeDude or zhasha can probably tell you best; I'm sure one of them has tried ;)
bridgman: and glisse, nha or airlied are your best bets re: status of classic mesa over kms/mm
ConnorBehan: I think MostAwesomeDude suggested a mesa tree that's more stable than gallium but still supports kms
ConnorBehan: I just can't find where I wrote it down
ConnorBehan: s/more stable/more ready
bridgman: my guess is that it would be the radeon-rewrite branch in mesa/mesa
bridgman: a few weeks ago it was probably somewhere different
bridgman: which GPU do you have ?
bridgman: http://airlied.livejournal.com/65755.html
ConnorBehan: radeon X1550
bridgman: probably ok; the r300 driver handles 3xx (eg 9700) through 5xx (eg X1550)
bridgman: not sure what airlied was using for testing though
bridgman: development branches tend to work best when you have the same card as the developer ;)
ConnorBehan: forgive my git ingnorance but when I clone git://anongit.freedesktop.org/mesa/drm that gets me some libdrm source code
ConnorBehan: but then I do git checkout --track -b modesetting-gem origin/modesetting-gem to turn that into the modesetting source code I actually want
bridgman: makes sense (modesetting code is in a branch) but the first command should be getting you more than just libdrm; should be linux-core, shared-core etc.. as well
ConnorBehan: if I wait a few days and run git pull origin will that update the code to the newest version of the modesetting branch?
bridgman: I'm not real good with git either
ConnorBehan: or will it revert it back to the old branch that I don't want?
bridgman: don't know, sorry
bridgman: lurkers; ping ;)
ConnorBehan: ok I need to find that out
bridgman: good luck with it
bridgman: gotta run, bbl
ConnorBehan: and I need to find out a mesa that runs over kms
bridgman: after looking through radeon-rewrite I'm about 99% sure that's what you want
ConnorBehan: and *hopefully* that mesa will be stable if my radeon driver is loaded with modeset=0, no matter how unstable it is with modeset=1
bridgman: mesa doesn't care about kms, it only cares about gem; but kms needs gem
ConnorBehan: oh ok thanks
ConnorBehan: I have to try that before I compile my DDX
bridgman: I don't know about running without modeset on; you'll need to ask one of the devs working on it
bridgman: anyways, have fun
bridgman: bbl
ConnorBehan: because I want to use --enable-dri for the DDX
rettub: sry I've asked before, but it seems you guys have a lot of knowledge :) So - I've probs with a radeon 9200pro RV280, on debian lenny, 2.6.26, amd XP2600 (burton?): 3D freezes any hints?
rettub: oh bridgman has gone ...
Posterdati: hi
Posterdati: please I got a problem with a radeon 9200 on A7M266: no dvi output to an acer al2216w
kcodyjr: bridgman, pong ;)
airlied: ConnorBehan: you want radeon-rewrite branch of mesa.
airlied: ConnorBehan: it should work if built against an install of libdrm from modesetting-gem
airlied: under non-kms and kms.
airlied: howeever non-kms isn't as stable as 7.2, it works mostly except compiz so far.
ConnorBehan: airlied: and to get frame rates comparable to what I have now I'd need to compile xf86-video-ati with --enable-dri which means I'll have to compile mesa before the DDX?
airlied: no need for --enabledir
airlied: it all automatic
airlied: if you are using my DDX
airlied: you want radeon-gem-cs2 brnch
airlied: under kms mesa is slower, I haven't even started on that yet.
ConnorBehan: ok so xf86-video-ati can be compiled before mesa and I'll still have direct rendering?
airlied: yes it doesn't depend on mesa at all
ConnorBehan: ok but the regular xf86-video-r128 must be linked to mesa with --enable-dri to have direct rendering right?
airlied: nope nothingh links to mesa
airlied: I don't think --enable-dri is ever really needed, its usually --disable-dri
airlied: it should detect DRI headers installed from the server
ConnorBehan: so my distro has makedepends=(..., mesa, ...) in the DDX build scripts for no reason
kcodyjr: ConnorBehan, direct rendering means the app communicates with the hardware itself rather than sending it to the server via X11 protocol. that's all. it doesn't imply 3D or anything else in particular.
ConnorBehan: but decent 3D performance usually requires direct rendering
kcodyjr: not necessarily; 'AIGLX' means accelerated indirect
kcodyjr: true that direct has a higher performance ceiling but indirect can be quite usable depending how hard you're hitting it
ConnorBehan: my log file says AIGLX enabled which implies I'm using indirect rendering
ConnorBehan: but glxinfo says direct rendering: Yes
adamk: You can have both direct rendering and accelerated indirect rendering enabled.
ConnorBehan: oh ok
adamk: And you can have direct rendering working via Mesa, and still using software rendering.
adamk: In fact, AIGLX will not enable in the X server if Direct Rendering is not enabled in the X server.
ConnorBehan: is the kms libdrm required to build the DDX and radeon-rewrite branch of mesa?
airlied: yes
airlied: at least the mesa bits
airlied: the DDX will need it eventually
ConnorBehan: and are the headers from the modesetting capable kernel required for building?
airlied: either those or the ones from libdrm modesetting-geem
ConnorBehan: will Driver "fbdev" when the modesetting radeon driver is providing /dev/fb0 eventually have performance comparable to Driver "radeon"?
airlied: no
benh: more to the point
benh: driver "fbdev" will be pointless :-)
airlied: I'm not sure it even works, I should probably at least make that bit work
ConnorBehan: I'm going to restart with the modesetting kernel and build the DDX now, cya
ndim: Compliment on dual-monitor handling in radeon. Now with the external display attached, I have not a single problem with the graphics driver making stupid things - just the desktop software is acting up.
ndim: M54 chipset, 1400x1050 LVDS plus 2048x1152 DVI.
ndim: OK, one small problem - the list of modes xrandr lists for the DVI display only contains a single one in 16:9, namely 2048x1152. However, for watching videos full-screen, something smaller in 16:9 would be useful.
da1l6: the list of modes is supplied from your display.
da1l6: to force another mode you have to add a custom modeline using xrandr --newmode or by editing xorg.cong
ndim: da1l6: OK, so I need to either google for a few modelines or start inventing/calculating one.
kcodyjr: ndim, what's wrong with the real resolution
kcodyjr: you're going to get crappier results with anything other than physical native, unless it's a high end crt
kcodyjr: wtf is with zxy_64 spinning in and out all day... messing up my scrollback
kcodyjr: yangman, ping
ndim: kcodyjr: If I want to watch a DVD movie on full-screen, the M54 cannot scale that out to 2048x1152 with a reasonable framerate. The zoom stuff in the TFT display can.
kcodyjr: the zoom stuff in the TFT is going to suck compared to using the gpu. why can't the M54 deal with it?
yangman: pong
kcodyjr: yangman; disturbingly, i've discovered a case that prohibits using the LUT for gamma correction
yangman: ndim: 2048x1152? that's an unusual setup
kcodyjr: and that case is where the digital output encoding is xvycc or similar that uses weird range mapping and a notion of negative values to maintain backward sRGB compatibility while also providing a wider gamut
kcodyjr: the LUT will be required to map a linear 0..255 in the wider gamut into the weird encoding
yangman: hm
kcodyjr: if those wide-gamut output modes are to be supported, gamma correction will have to be done with shaders
ndim: kcodyjr: No idea why the M54 cannot scale that. Fact is that the fullscreen video has 5..10fps, and that is not enough for me.
kcodyjr: are you using Xv ?
ndim: yangman: Yupp. 23" 2048x1152, i.e >100 ppi.
ndim: Samsung 2343BW.
ndim: kcodyjr: Should be using Xv, yes.
ndim: Hmm... interesting.
kcodyjr: M54 is what chip series?
ndim: Funnily, on testing again, it appears to be able to scale it up after all?
ndim: kcodyjr: R5xx
kcodyjr: that should be able to handle a 2K+ buffer
kcodyjr: it ought to be working at the native resolution with full acceleration up to hundreds of fps. i'm not sure why it isn't but i suggest pursuing the problem from that perspective.
ndim: Working on that.... uhm... watching videos, I mean. :)
kcodyjr: ;)
agd5f: ndim: you can also enable the panel scaler
agd5f: xrandr --output DVI-0 --set scaler full
agd5f: that will use the GPU panel scaler rather than the monitor's scaler
kcodyjr: what agd5f says is certainly better than using the tft's scaler, though not as good as getting a native resolution framebuffer
ndim: agd5f: That would go together with a custom lower-than-native-resolution modeline, right?
agd5f: ndim: right. if you enable the panel scaler it will kick in when you select a non-native mode
agd5f: ndim: if you want to use the monitor's scaler, turn off the scaler option
agd5f: with xrandr
ndim: Good. Makes sense. I guess this dual screen thing is going to take a lot of experimenting with software settings and code. Great investment as a toy :)
bridgman: ndim; M54 is RV515, I think, so you probably *just* have enough shader power for Xv scaling at that res but are probably running out of memory bandwidth
bridgman: not sure if bicubic Xv scaling is enabled by default on your GPU but I think it is; if there's an option to disable bicubic then I bet you could run ok
bridgman: unless you're running a compositor as well, in which case you might be SOL unless you're running full screen with a compositor that can unredirect a full screen window
rnoland: adamk: ping
kcodyjr: keep missing that guy.
rehabdoll: ,
ConnorBehan: are you sure I don't need to recompile the xserver to get the DDX working?
ConnorBehan: airlied: is xf86-video-ati supposed to depend on dri2.h?
ConnorBehan: does anyone know a way around dri2.h for starting x with direct rendering using the modesetting radeon driver?
kcodyjr: ConnorBehan, i ran into this too. no. you will need to recompile the xserver plus a bunch of dependencies.
ConnorBehan: kcodyjr: do you know the git urls?
rnoland: hrm, i need to put my hands on some r6/7 hardware....
kcodyjr: ConnorBehan, not offhand. i used the gentoo overlay.
ConnorBehan: oh the xorg-server-1.5.99.903 release has dri2.h, anything wrong with using that?
rnoland: ConnorBehan: should be fine.
ConnorBehan: any heads up as to what the dependencies are that must be recompiled?
rnoland: um, don't have a clue what you have...
rnoland: on freebsd, only randr bits....
rnoland: and then recompile your drivers after the server
kcodyjr: including input drivers and such
ConnorBehan: the input drivers don't need to come from git right?
ConnorBehan: they could be the same one's I use now as long as I recompile them so they relink with the server?
kcodyjr: for the most part; there are some changes i think, evdev input and such
ConnorBehan: I'm using 1.5.3 so I already have input hotplugging
ConnorBehan: is there a reason for the big version number jump?
rnoland: ConnorBehan: still need to rebuild your drivers against the new server
ConnorBehan: ok but I can rebuild the same source code
rnoland: yes, just need them build against the right server.
ConnorBehan: is there a reason it goes from 1.5.3 to 1.5.99 and not 1.5.4?
rnoland: it's the 1.6 rc line
ConnorBehan: so my distro would probably be opposed to packaging it for me =\
rnoland: yep
ConnorBehan: I thought there were spammers here for a second, but then I remembered I had tabbed over to #archlinux
ConnorBehan: well thanks alot, I'll get on recompiling the xserver
ConnorBehan: any projections as to when 1.6 will come out?
ConnorBehan: I'm happy to compile it myself, but if 1.6 is due in less than a week I might as well wait