ali1234
Not working
Hi,
this is not working on my pc. Neither in Firefox nor in Google Chrome, on not a single flash-video I found. I've tested this before it was released on git (didn't worked back then neither) but now I can report it. The script detects the correct display size and founds a lot of matches when I start it with the browsers - no errors found (in cerr or cout). I'm using the following software: System: Gentoo 64 bit Chrome: 21.0.1161.0_alpha (didn't worked back then when I had stable and beta versions) Firefox: 10.0.5
I'm using nvidia twinview, NO xinerama at all (since it's buggy, needs a lot of resources, etc).
Btw you should either remove the executable from git, or add the "make clean" command to the readme, since "make" will not recompile the executable if it's still there.
Firstly, systems without Xinerama are not supported.
Secondly, there is no binary in the repo, and never has been.
First: you should mention that somewhere second: point taken, but a simple make without a make clean doesn't work at least on my pc - so something has to be there. 3rd: thanks for your reply. 4th: could you make it work without xinerama? Xinerama destroys my fps in every game, ruins a lot of programs if used with twinview and I simply don't want to use it. And I hate to downloda every videos via plugins in my browsers since there's not realy any other fix. (I'm thinking about running a windows version of some browser inside a wine desktop, since I think that will work, but seriously?)
If you tell me how to set up a system which has twinview but not xinerama I will take a look at it. But I can't guarantee I will be able to fix it.
make works fine for me and I use it all the time when testing without doing make clean.
Actually, your xorg.conf, Xorg.0.log and output from make test should be enough for me to figure out what is happening.
I'm at work, while my pc is at home. So I'll give you those informations later. I simply let nvidia-settings create my xorg.conf (thought I may change something, but it appears in every config I've tried). Xinerama usually is for more then one xserver since twinview only uses one, it's not nessessary. I've installed the lib though (since you linked against libXinerama). The output from make test was correct (I can't recitate it 100% accurate) it told me: without hack: 2560x1024 with hack: 1280x1024 which is correct, but flash just did ignore and kept rendering at 2560 width.
does the flash window cover more than one monitor?
also do you use 64 bit flash plugin? do you use ndiswrapper?
no. I'm running chrome/firefox (same with both) maximized on one screen (1280x1024+0+0) click fullscreen on a flash movie and it renders on 2560x1024 but only the left half of it is visible. I've tried to use windowed mode in the browsers and resize them over both monitors - but the fullscreen of flash keeps maximizing on screen 1 the movie is only half visible.
I'm using the 64 bit plugins.
ok. in that case, and given that the make test correctly identified your screen resolution, means you have a working xinerama setup.
nvidia twinview provides a xinerama-like api even if real Xorg xinerama is disabled. this is for compatability with window managers, so that a window can be maximized on a single display even there is really only one X11 display.
this means the problem is something to do with the way you are applying the library.
i have seen problems with chrome before, where chrome installs a shell-script in /usr/bin/chrome. the script messes with the environment. you need to check it.
for firefox, you need to make sure that you are not using nspluginwrapper. if you preload the 64 bit library with 64 bit firefox but are using ndiswrapper with either 64 bit or 32 bit flash then it will not work. in this case you have to add the preload to the nspluginwrapper environment, which is done in the nsplayer script. but you still have to compile it for the right architecture.
I'm using gentoo, so if I tell my "package manager" to compile the 32 bit it adds the depency: "ndiswrapper" which is NOT installed on my system. So I'm definitly not using ndiswrapper (at least in firefox, as I said chrome is a binary which includes the flash player, it MAY use ndiswrapper internally). I've tried different approaches to apply the hack, I've edited the chrome file. Recently I focused on firefox, since I thought that it may easier to apply it there (and I know there's no ndiswrapper) - when I preload your hack and start firefox it prints a lot lines where it has found and replaced the resolution, so I guess it applied correctly.
sorry, ndiswrapper is the wrong thing. that's for windows network card drivers on linux. you actually need to check for nspluginwrapper. i always get them mixed up because they have similar names and similar purpose.
chrome never uses nspluginwrapper at all.
you will still see messages from the wrapper even if flash isn't using it - because firefox itself calls the same wrapped functions. you should see the library "loaded" message several times because each child process of firefox (of which plugins are one possible type) will inherit the environment variable and thus load the library again.
i'm assuming you changed Makefile to BITS=64?
I did change the makefile. I think I've searched for nspluginwrapper, but I may have mixed it up as well, I'll check this evening. Anyways I've got options in flashplugign "32bit" and "64bit" and I know I've NOT set 32bit but I've set 64bit, so I should not use nspluginwrapper for this. But if chrome doesn't use it anyways, why doesn't it work in chrome neither? I think it's something else. What are the differences in our systems? Have you tried to compile a firefox by yourself? Under a 64bit system? Maybe we could reproduce this on your side. If it's of any help, I know how to program, including C++ (and a bit C), I've just not written any hacks (thought I've used a dynamic library as a plugin).
I use Ubuntu 64 bit. I have not tried to compile firefox from source, but if I did I would use dpkg-buildpackage and get a result identical to the binary that I have installed anyway. I also use 64 bit flash now, but i developed the plugin when using 32 bit flash with nspluginwrapper, as there was no 64 bit flash back then. I also have reports of it working with chrome - at least on older versions.
You can check the architecture of the flashplugin.so (or any file) by "file flashplugin.so" - it will probably be in /usr/lib/firefox/plugins or /usr/lib/mozilla/plugins or some similar directory. perhaps you need to follow a chain of symlinks to find the real binary.
I'll check that when I'm at home, I already found the correct file on my (single monitor 32bit gentoo) notebook: "/opt/Adobe/flash-player/flash-plugin/libflashplayer.so" I guess there should be "ELF 64-bit" on my desktop pc. To give you the time when I'll be home: 6 pm GMT (more or less)
/opt/Adobe/flash-player/flash-plugin/libflashplayer.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped Xorg.0.log: http://pastebin.com/raw.php?i=RB8UVCSb xorg.conf: http://pastebin.com/7KLxZsfj
I've just recognized, there's an error (without your hack as well) when pepper (chrome-flashplugin) is trying to fullscreen some video:
[25:25:3258100325:ERROR:render_widget_fullscreen_pepper.cc(187)] Not implemented reached in virtual void
I think that is the problem with Chrome. It uses a different plugin API and looks like different code to go fullscreen. Still not sure why Firefox doesn't work though.
Ok so I installed google-chrome and verified that the plugin works with it.
ran it as:
LD_PRELOAD=/home/al/Source/fullschreenhack/libfullscreenhack.so google-chrome
The wrapper works as expected with or without hardware acceleration enabled. No errors about pepper API were reported. Using Chrome Version 19.0.1084.56
I've used those paths in the command (well mine of course) but still. Here's my chrome:about (partly)
Google Chrome 21.0.1180.4 (Offizieller Build 143399) dev Betriebssystem Linux WebKit 537.1 (@120872) JavaScript V8 3.11.10.11 Flash 11.3.31.208
Btw I've seen adobe-flash will not release any further flash plugins for linux version 11 is the last one. So I gotta fix this or I'll never be able to watch flash videos without starting a second X on :1 (which realy sucks, since I need to close my browser on the first X).
Not true. Adobe will continue to release updates for the Pepper API version of Flash plugin, but this version will only work with Chrome and Chromium. Adobe will no longer support NPAPI.
Not really. You could try to ltrace it, that's how I made the hack in the first place.
I've tried to. Chrome openes new instances for each tab, so the main process doesn't load any plugins. And firefox uses plugin-container for flash. I've disabled it which resulted in Sigfaults everytime a plugin is needed. The fork option (in ltrace) caused both programs to crash instantly (even with -L). Btw firefox also didn't start if I simply tried to track something in it (it worked with -L but was not usefull anyways). Could you provide me the correct command please? Btw: The -d option didn't helped me at all when it crashed
I've compiled chromium now, it more or less prints equal output thin chrome (with your hack) but the result is also the same. In case you don't know: Chromium is opensource (while Chrome is not) and using the "real" adobe flash player (not the google-chrome one). So I could check the entire source-code if nessessary. Anyways I doubt that this is a browser-issue, it's rather a flash issue - which is closed source - so a hack is the only way. I still don't realy have a clue how I could fix this. I've tried to attach to the chromium tab process with strace and greped for 1280 and 2560 (width of 1 or both screens) but neither gave any output - while the output for 1024 (height) was that high (but not relevant) that it stoped chromium from working. Exact same results in chrome and firefox. btw if I try ltrace instead it just prints out "SIGSTOP" twice, and the process freezes - no idea if that's the usual behaviour.
//EDIT: I have an idea!!: I've checked the symbols of flashplugin.so and found some gtk functions. one of them is gdk_screen_width. So I've written a very simple program which prints me out the value of gdk_screen_width. And no matter of your hack it always returns 2560 which is BAD. At least I found the problem, I assume I'm having a newer version of flashplayer which uses gtk to get the screen dimensions instead of xinerama. I think I'll try to fix this a little bit, but if there's no easy fix, I'll leave that to you (since I pointed out the potential problem now). //EDIT 2: Nvm, I wrote my own hack (my first, yay) which actually simply divided the screen-width by 2, but no browser did care about it :(. Still same issue.
I found now a solution I can live with. There's a chrome addon which is called "MaximizeFlash" and it works on everything that uses flashplayer. It simply maximizes flash inside a tab - in combination with fullscreen (F11) that's a working fullscreen flash. So I haven't fixed your hack, I just got an other way to run fullscreen flash. Everyone else who's having my problems with your hack may read this and follow my solution.
Anyways if you fix this someday, just let me know.
Not without your mailadress, but I've uploaded it here: http://www.file-upload.net/download-4516448/libflashplayer.so.html that link doesn't work well so here's an other one: https://rapidshare.com/files/2073491696/libflashplayer.so
It works in Firefox for me and not in Chrome. Maybe your hack does not support pepper api flash?
Linked libflashplayer.so isn't pepper API. Actually it is identical to mine.
Just to let you know that I have a fix for flash under linux 64bits with nvidia. And no need for Xinerama too (with firefox only, I didn't check if chrome is working) :) I just need to clean the makefile a bit and I will submit the patch
