WebGL
- Anmelden oder Registrieren um Kommentare zu schreiben
Aaand another issue:
WebGL doesn't work with ABrowser on my machine. Whenever I go to http://get.webgl.org/ I get the following:
"Hmm. While your browser seems to support WebGL, it is disabled or unavailable. If possible, please ensure that you are running the latest drivers for your video card."
lshw tells me the following in its display section:
"
description: VGA compatible controller
product: Core Processor Integrated Graphics Controller
vendor: Intel Corporation
"
Which packages do I need? Any help is highly appreciated.
Paste this to the location bar of Abrowser and hit enter, dismiss the warning if this is your first time.
about:support#graphics-tbody
Then paste the gfx section here.
Ok, here we go:
"Graphics
Adapter DescriptionGLXtest process failed (exited with status 1): GLX extension missing
GPU Accelerated Windows0/1 Basic Blocked for your graphics driver version. Try updating your graphics driver to version or newer.WebGL RendererBlocked for your graphics card because of unresolved driver issues."
You might need to install some glx related package?
One thing you could try is going to Abrowser and inputting about:config to the location bar and hitting enter. Dismiss the warning it it comes up. There you might try setting webgl.force-enabled to true. I don't know what happens if you do though!
I already tried that but unfortunately it doesn't help either...
"You might need to install some glx related package?"
Which one? :-)
I have Abrowser 22 and http://get.webgl.org/ is working fine for me. I see that cube moving.
I have latest xorg drivers, glx dri, glx dri experimental and libre kernel 3.10. But I don't know how to help you.
I have the below ppa (from ubuntu launchpad) with latest drivers installed:
xorg-edgers.
Thank you, dadix. In another thread you mentioned the Intel Open Source drivers. Where did you get them from and how did you install them? Maybe I just need these to fix my problem.
The drivers for intel is the package: xserver-xorg-video-intel . You can see it in synaptic.
Look in synaptic and install the package from bottom screen shoots:
http://postimg.org/image/f4scnivyb/
http://postimg.org/image/fusghudxj/
http://postimg.org/image/k4nn54imh/
http://postimg.org/image/4fptkyhmp/
http://postimg.org/image/hxmm31joz/
If you don't have those names packages than I think you may install the ppa from botton but,
Attention:
I don't know if this package are free of blobs, because is not from Trisquel repos.
Can someone tell us if those packages which are downloaded from xorg-edgers have blobs or not?
You can install:
sudo add-apt-repository ppa:xorg-edgers/ppa
sudo apt-get update
sudo apt-get upgrade
Also new mesa drivers requaire kernel 3.6 or newer. For my is working with a libre kernel 3.10.
I wrote an email to xorg-edgers in the past and they said they have no policy considering licensing and do have (or was it might have) some non-free content.
I have no idea about those packages.
Does it work for somebody using vanilla Trisquel?
I think is working without this ppa. I removed xorg from my system , that ppa from above and I reinstalled only from trisquel repos. I still have my 3.10 libre-kernel
sudo apt-get install libgl1-mesa-glx libgl1-mesa-dri-experimental libtxc-dxtn-s2tc0 libtxc-dxtn-s2tc-bin
I see that cube moving.
Sounds like a good thing that it's disabled. I mean, really now. Really now. Who thought letting any random website execute whatever it damn well pleases directly on the GPU sounded like a good idea?
That's not exactly what WebGL does. It's an API for rendering graphics; yes, the GPU is directly used for this normally, but it's not like the code directly tells the GPU what to do. It tells the browser what to tell the GPU to do (though I think it's more like telling the browser what to tell the OS what to tell the GPU to do).
The reason it might be a good idea might be to get rid of proprietary plug-ins that have been used for the job, like Flash and Unity3D. I think it's a good standard to have. The only reason to have it disabled by default might be to prevent unwanted slowdowns and discourage web developers from abusing it for stupid things (like when some people had entire websites based on Flash).
Sure, and technically Java is supposed to be a perfectly safe plugin, and ideally all implemented code should be bug-free.
You're also wrong on one point, WebGL, as the name implies, is a way to make OpenGL calls to the GPU via JavaScript. WebGL lets any website push shader code to the GPU. Yes, it's an API, and it's also as close to metal of the GPU as most native software ever gets.
Quite frankly, JavaScript is already overpowered, and browsers already have more than their share of security problems, why the hell would one wanna add one more attack vector to the mix?
Don't mix up Java and Javascript. They're two completely different things. Java applets require a plugin (IcedTea for OpenJDK) to work in a browser, and Java is known to be insecure, though I got the impression when reading this that this was mostly the proprietary implementation. Javascript is a language interpreted by web browsers directly; it doesn't need a plugin. WebGL is a standard for Javascript, not Java.
Yes, I know that WebGL provides a way to give specific instructions to the GPU, though I don't really know much about that. It's still giving these instructions to the browser, though, and the browser has to pass the instructions along. Of course it's bad when browsers do this automatically, but that's because they end up executing proprietary software on your computer, and this happens with a lot of Javascript code already. It's a separate problem that won't be made any worse by a graphics rendering standard.
I suppose my real question is: what's so bad about web applications using the GPU "directly", as you say (giving more low-level instructions, I take it)? Unless there are instructions that can make your GPU melt itself, I can't think of any possible security problems that could be introduced by that. All I can think of is that maybe some dickhead could tell the GPU to start screwing with the display by making it all purple or something, which would be malicious, but it doesn't have a chance to compromise security in any really meaningful way; it's just annoyware. And since, as I say, it has to pass through the browser, if something stupid like that gets prominent, browsers can offer a way to disable all WebGL code currently running, and if it's disabled by default (which I think is a good idea to prevent abuse of the API for things it's not designed for), that kind of code wouldn't work in the first place.
I'm not mixing them up. Merely illustrating the point that giving websites too much power to execute anything but properly sandboxed, constrained code is a bad thing.
It's in fact a somewhat good way to contrast, JavaScript is an interpreted scripting language that's heavily sandboxed, and Java is a powerful, compiled, full-featured language that can be used for heavy-duty applications. JavaScript was made with a browser in mind, Java was made with a powerful, cross-platform programming language in mind. Trying to shoehorn it into a sandbox for the web long after the fact has had some rather predictable results.
WebGL is an OpenGL API exposed by way by JavaScript, never claimed it had anything to do with Java, and Java has it's own libraries of OpenGL bindings anyway.
The freedom issue is unrelated to the security issue, which is what I'm talking about.
Point is, all software has bugs, that's just the reality. Ideally speaking, due to proper sandboxing and the browser running with limited priviledges, and NX bits, the worst thing a bug in a javascript interpreter can do is crash your browser. Again, ideally speaking.
Now contrast that with a decent dedicated GPU, more or a less a powerful computer in itself, and consider what some bugs in the WebGL, or even the graphics driver, might enable.
..Well yeah, of course it passes through the browser, and the browser controls if and when to make these calls avaliable. And "modern" browsers btw all have this enabled by default. Even mobile browsers.
Obviously I'm being paranoid here. Probably much, much too paranoid, but history has proven time and time again, the very concept of exposing powerful lower-level features / API's / whatever to the web is quite frankly just a bad idea.
Flash, Java, ActiveX, they've all been security nightmares, oh so powerful and oh so convenient at times, but still security nightmares. While WebGL isn't the same thing, is limited to shader code and can't do too awful much in theory, it's still another potentially nasty attack vector, and it's still trading security for.. Eh.. Well, I donno, the ability to play doom in your browser?
I still don't understand what the security risk is. The GPU can't steal personal information, corrupt your hard drive, blow up your computer, or crash a plane. It just controls the display.
> for.. Eh.. Well, I donno, the ability to play doom in your browser?
Maybe it's not a great use of web browsers, but the fact is that games hosted on the web are popular, and they use Flash or Unity3D most of the time. Most of the time they're proprietary themselves, so it doesn't make much of a difference on an ethical level, but any proprietary plugin being popular is a disservice. If the proprietary web-based games are using a free standard, it's a lot easier to make it ethical (they just need to release the source code under a free license), and ethical competition can exist.
...The risk is one more place to look for bugs and make exploits.
And let's not forget, the GPU these days is more or a less a small computer physically attached to a larger computer, a small computer which by the way has direct and full access to all system RAM.
Not to mention it literally sees everything you're doing.
Translation: It CAN steal personal information and it probably CAN corrupt your harddrive and, if not blow something up, at least crash the system pretty thoroughly.
And if that system happened to be flying a plane.. ..Then I say something has definately gone wrong in the plane design department.. XD
Then again, hell, once upon a time they used Windows NT to run cash registers and bank terminals, who knows what's going on in planes these days. =P
And again: I'm being overly paranoid here. =x
I actually like the KISS.... Keep It Small and Simple.
I like websites that use html, css, some free non-malicious javascript... All that hype about flash and such, was a real pain in the back all the way through.
I hope as we move away from flash (thanks to html5) we don't get into another "frenzy" like that.
@dadix: libdrm-nouveau2 was the package I was missing. Thank you! You sir, are rocking very much! :-)
- Anmelden oder Registrieren um Kommentare zu schreiben