| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9
Comments:
<0> SunTzuTech: If it the only way to do it, why not integrating the script
<1> you can run qemu as root, but I've seen pbrooks comments on that. :-)
<2> SunTzuTech: I read that too ;)
<2> SunTzuTech: stressing on "none" ;)
<1> When I finally got the tap patch working, I knew I was going to have to supply a SUID script
<3> oh fun fun
<4> SunTzuTech: Do SUID scripts really work on slowaris?
<1> AFAIK, no tunctl for Solaris
<1> pbrook: it's actually c code, so technically, it's a SETUID wrapper
<1> It was a good morning. Both TAP and KQEMU on SOlaris 10
<1> the_hydra: yeah, it gets that reference from some folks
<1> well, I'll knock out the Makefile changes for the setuid wrapper.
<5> is there a way to grab kqemu from cvs?
<6> fine, leave as I'm typing my answer
<6> see if I care
<7> kqemu got a cvs ? when ?
<6> my answer was 'unless it got one within the last hour, no' :)
<7> ;)
<2> gtg all
<4> Hmm. "Small performance hit" seems to be rather larger than I expected. Booting linux goes from 1m24 to 1m53
<7> cya all ... bight
<8> if i run qemu full screen.. how do i unfull-=scree it
<7> *night
<4> SirFunk: Same way tyou made it fullscreen in the first place: c-a-f.
<8> ahh
<8> i made ifull screen with -full-screen :-P
<8> hmm
<8> full screen screws up my X resolution
<8> my deskto pnow goes off the end of my screen and is all streched
<8> oh.. xvidtune saved me :-P
<8> is there any way to get weird resolutions like 1280x800?
<8> in qemu with windows
<6> I don't know if -std-vga would help, but you could try
<6> otoh, I doubt vbe does that resolution
<8> :-\
<8> darn
<6> ohh
<6> seems mode '352' is used (unofficially) for 1280x800 (8-bit)
<6> support for that could probably be added, if it's not there already
<6> argh, except it's normally used for 1440x900. urgh :(
<8> would it be possible for me to patch it?
<8> like for myself
<8> i don't know what goes into video bios stuff :-P
<8> it kinda ****s runnning qemu at 800x600 though (too small) and then 1024x768 goes off the bottom of my desktop because of the windowmanager bar at the top :-P
<8> and if i full-screen 1024x768 it gets streched
<0> pbrook: can you locate the part of the translation which takes most of the time ?
<4> hint: All of it :-(
<4> I'll see if I can do some instrumentation to compare the regalloc p*** with the actual codegen p***.
<6> SirFunk: gotta agree, that does ****. ideally you'd be able to run at any arbitrary resolution... if only it were that simple :(
<8> :-)
<6> SirFunk: it would obviously be possible to kludge this. you'd need to do coding for the guest, though.
<6> for X.org, I imagine you could get it so that the user can simply resize the qemu window.
<8> that woudl be cool, i udually use windows in my qemu's for now though
<8> grr
<6> I bet windows keeps a static list of video modes, which you could edit, but you'd probably have to reboot afterwards
<6> SirFunk: yeah... well, it'd be nice to have a set of free drivers for windows, imo
<9> i have an idea about improving the available resolutions
<9> i was going to try and see if it works today or tomorrow
<10> balrog-kun: oh?
<10> how would u do it?
<9> the idea is emulating the "vmware" video card,
<9> it must be a simple one, and it's got drivers in X.org
<10> ahh
<10> and it already supports arbiturary resolutions in both x.org guests and windows guests
<11> balrog-kun: i thought of that too.. the problem is it's a hybrid
<11> it's whatever driver they support, extended to have a bunch of new features
<9> so it depends on other vmware hardware too?
<11> balrog-kun: on the hardware they emulate, yeah
<9> i see
<11> i was hoping it would be super easy to get setup
<9> yeah, i was hoping so too :p
<11> balrog-kun: i was thinking that implementing the vmmouse driver might be cool though
<10> i wonder if vbox supports arbitrary resolutions, since they also have a special guest video driver
<9> we could have "-M vmware-pc" some day
<11> balrog-kun: the other thing is that you can't just get the windows drivers unfortunately.
<10> as well as guest mouse drivers
<11> the eula prohibits use outside of vmware
<10> all open source, unlike vmware
<9> well, i guess you could make a windows driver quite easily if you really cared
<9> because there is one opensource driver
<11> might as well just extend the cirrus driver then
<10> oh nvm, vbox's graphic driver only supports X guests
<9> cirrus will never allow for resizing the display when you resize qemu window i'm afraid
<8> damn
<8> i almost got it to work in windows with: http://www.mp3car.com/vbulletin/showthread.php?t=42122
<8> however when i tried to go full screen it crashed
<8> with "Cannot open sdl window"
<8> but the windowed mode was running 1280x800
<9> and the vmware hardware should be not very difficult
<10> balrog-kun: aliguori: i still think it might be easier to interoperate with virtualbox guest additions instead of vmware tools.
<11> balrog-kun: we could "extend" the cirrus emulation and then send patches to Xorg
<11> that would work for linux at least
<11> iamfound: no point in working with things that aren't upstream IMHO
<11> vmware at least has gotten a good number of their things upstream
<10> aliguori: what do u mean by upstream?
<11> iamfound: the graphics driver is in Xorg
<11> for instance
<11> you don't have to install anything to use it
<6> presumably hardware vendors shouldn't bother making cards that need new drivers, too? yeah, yeah... I do get the point.
<6> it's /better/ to emulate real things
<10> aliguori: that is a very good point, but the fact taht the same drivers wouldn't work is a real killer imeho
<10> (in my extremely humble opinion)
<6> but I wouldn't say 'no point' exactly...
<11> iamfound: what do you mean, "the same drivers"?
<10> aliguori: sorry, i meant "the same graphics drivers for windows guests"
<11> oh
<11> windows drivers another can of worms
<11> i'm not sure one can have gpl windows drivers?
<6> we could do with something :)
<10> aliguori: we can have GPL windows file systems :)
<10> i cant imagine GPL windows drivers would be much harder
<11> iamfound: if non-GPL kernel modules are illegal, then GPL-d modules in a non-GPL'd OS have to be illegal too
<11> although IANAL
<9> modules can be non-GPL, only if compiled into the kernel they whole binary has to be GPL (or BSD etc)
<9> there is no way to restrict the licenses for binaries that are in separate files afaik
<6> remember, it's GPL + confusing exception
<10> aliguori: GPL only covers distribution, so its a non issue as nobody is talking about distributing a windows kernel along wiht these drivers. windows drivers are a bit different as they dont directly link with the kernel in windows anyways, they run in ring 0 but they talk to the kernel via an api.
<4> iamfound: Actually, people do distribute windows drivers with the kernel. Pretty much every OEM PC you buy does.
<10> pbrook: this is relevant how?
<4> "nobody is talking about distributing a windows kernel along wiht these drivers."
<6> our own drivers :)
<10> pbrook: you are proposing that we sign up an OEM to sell qemu video drivers along wiht windows vista? :)
<6> if we can do that, maybe we can force them to drop their drm ;)
<4> iamfound: You might not want to do that, but eg. win4lin might.
<10> actually, even then it probably wouldn't be an issue since a) we're not linking the driver to the kernel (windows drivers access the kernel thru a standard API iiuc) and b) the GPL has an exception for things along the lines of libc (if its part of the OS and the user will have it anyways then that part doesnt have to be open source, to paraphrase it)
<4> iamfound: A standard API doesn't isolate you from the GPL.
<4> The GPL has a special exception for the OS syscall layer, whether that applies in this case is a grey area at best.
<10> pbrook: you are right.
<8> bah, nexenta takes FOREVER to install in qemu :-P
<10> pbrook: the best we can do is to use a GPL compatible liecense, like BSD or a GPL license with a special exception for distributing with windows
<11> iamfound: there is no right/wrong with licensing. it's how comfortable do lawyers feel. and i strongly suspect that this sort of thing makes lawyers very uneasy :-)
<11> iamfound: you aren't allowed to do that with the GPL
<11> you have to get exceptions approved by the FSF
<4> Technically what you're doing is inventing a new licence that's GPL compatible.
<10> aliguori: then we just go BSD
<10> pbrook: yes
<11> iamfound: but you were previously talking about reusing the vbox drivers. those are gpl
<11> if we are writing drivers from scratch, licensing isn't an issue
<12> but the vbox windows drivers are linked with the ms ddk
<4> vbox it not a good example. They appear to be happy to play fast-and-loose with licencing.
<10> aliguori: i made a mistake about that, the driver we're interested in, the guest graphics driver, exists only for linux
<12> pbrook: including things they put in the svn which they now claim are non free and can't be distributed.
<12> (without permission.)
<4> Yeah. Their licencing FAQ is wrong in several ways.
<10> aliguori: so we can't use vbox anyways.
<10> here's an example of a non filesystem GPL drriver foor windows: http://btwincap.sourceforge.net/
<11> iamfound: just b/c they are out there, does not make them kosher :-)
Return to
#qemu
or
Go to some related
logs:
inside fgxi
#web
gtktreeview row_activated row selected
#debian
ubuntu mouse speed problem
vsftpd openssl/err.
#web
growisofs remount someone was in time
#web
#perl
|
|