WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 81456
18638
Add support for non X11 unix platforms
https://bugs.webkit.org/show_bug.cgi?id=18638
Summary
Add support for non X11 unix platforms
Michael Emmel
Reported
2008-04-20 12:51:47 PDT
Added XP_X11 and XP_DIRECTFB ifdefs and platform support for DirectFB
Attachments
Add Platform definiontion and ifdefs for DirectFB add X11 specific def
(2.32 KB, patch)
2008-04-20 12:54 PDT
,
Michael Emmel
no flags
Details
Formatted Diff
Diff
Add changelog entry to original patch
(2.89 KB, patch)
2008-04-20 13:00 PDT
,
Michael Emmel
mrowe
: review-
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Michael Emmel
Comment 1
2008-04-20 12:54:19 PDT
Created
attachment 20702
[details]
Add Platform definiontion and ifdefs for DirectFB add X11 specific def This is probably a bit controversial since I went the route of adding XP_X11 but it makes the most sense and follows the logic WebKit took for multiple graphics stacks and operating systems.
Michael Emmel
Comment 2
2008-04-20 13:00:53 PDT
Created
attachment 20705
[details]
Add changelog entry to original patch
Eric Seidel (no email)
Comment 3
2008-06-06 10:07:56 PDT
Comment on
attachment 20705
[details]
Add changelog entry to original patch Looks fine to me.
Darin Adler
Comment 4
2008-06-08 12:04:43 PDT
Comment on
attachment 20705
[details]
Add changelog entry to original patch I'm not sure this patch is OK to land. It seems to change the npapi.h header so that it requires a new symbol, XP_X11 to be set to make it work as it did before. What is going to set that symbol outside the WebKit project?
Michael Emmel
Comment 5
2008-06-08 14:08:39 PDT
This would result in a proposed change to the plugin header that would need to be propagated back to Mozilla. I'd argue that its needed even in the case of Mozilla which is supported on gtk/directfb. I don't know who is responsible for the interaction between Mozilla and WebKit.
Mark Rowe (bdash)
Comment 6
2008-07-26 22:16:09 PDT
Comment on
attachment 20705
[details]
Add changelog entry to original patch Setting as r- per Darin's concerns in
Comment #4
. We can't make changes like this to an API header file without them being discussed with Mozilla first.
Sriram Neelakandan
Comment 7
2012-04-15 21:20:22 PDT
Mozilla has already made some changes along these line to ensure inclusion of X11 headers under MOZ_X11; Please see the latest file here on the NPAPI SDK link that i found on the plugin-futures wiki page (
https://wiki.mozilla.org/NPAPI#NPAPI_SDK
) The Latest NPAPI Header as per Mozilla's NPAPI SDK
http://code.google.com/p/npapi-sdk/source/browse/trunk/headers/npapi.h
And this dates back to r2 on the Version trunk which already had MOZ_X11 protection flags
http://code.google.com/p/npapi-sdk/source/diff?spec=svn2&r=2&format=side&path=/trunk/headers/npapi.h
Interesting fact is the first version import of the NPAPI header has npapi.h:104 #define NP_VERSION_MINOR 27 where as webkit trunk is @ npapi.h:103 #define NP_VERSION_MINOR 24 So is there a policy on how often Webkit updates NPAPI headers ? Or should i just pull that file from npapi-SDK and submit as a patch for review ?
Eric Seidel (no email)
Comment 8
2012-04-15 21:25:58 PDT
I'm not sure who the right plugin people are for NPAPI these days, but not me. :)
Stuart Morgan
Comment 9
2012-04-15 21:47:46 PDT
(In reply to
comment #7
)
> So is there a policy on how often Webkit updates NPAPI headers ? > Or should i just pull that file from npapi-SDK and submit as a patch for review ?
The reason you see divergence is that the npapi-sdk project is quite new in the history of NPAPI; until recently, there was no single source, and each browser vendor had their own copies of the headers that had diverged a fair amount. Work has been done to bring WebKit much closer to the new upstream header, but it was never finished (see
bug 38666
,
bug 77200
, and the various bugs they reference). I'd recommend strongly against trying to check in the upstream headers directly as a single patch, and instead pick out the differences specifically related to the MOZ_X11 guard and reconcile just those in one patch.
Michael Emmel
Comment 10
2012-04-15 22:05:17 PDT
(In reply to
comment #9
)
> (In reply to
comment #7
) > > So is there a policy on how often Webkit updates NPAPI headers ? > > Or should i just pull that file from npapi-SDK and submit as a patch for review ? > > The reason you see divergence is that the npapi-sdk project is quite new in the history of NPAPI; until recently, there was no single source, and each browser vendor had their own copies of the headers that had diverged a fair amount. Work has been done to bring WebKit much closer to the new upstream header, but it was never finished (see
bug 38666
,
bug 77200
, and the various bugs they reference). > > I'd recommend strongly against trying to check in the upstream headers directly as a single patch, and instead pick out the differences specifically related to the MOZ_X11 guard and reconcile just those in one patch.
But why have platform types in this header ? They can readily be moved to a included platform header along with platform specific entry points. The EGL bindings do a fairly good job of isolating platform types and can server as a template. Where needed you have NativeDisplay. NativeWindow etc. On top of this both WebKit and Mozilla have and extensive porting layer very few plugins actually need direct access to the underlying platform. Exporting the porting layer as a target for plugins suffices for 90% or more of the plugins. Flash for example could be trivially ported to both browsers porting layers. With HTML 5 the api is effectively complete in the porting layer. This is perhaps going beyond this bug report. But recognize the need of and api for native extensions that makes far more sense then the current plugin concept. Almost all plugins should be ported to a new native extension api synchronized between browsers. A small number will need to bypass this.
Sriram Neelakandan
Comment 11
2012-04-15 22:49:13 PDT
(In reply to
comment #9
)
> instead pick out the differences specifically related to the MOZ_X11 guard and reconcile just those in one patch.
Then as a first step; I am preparing a patch which will have the MOZ_X11 changes against npapi-sdk@r14 for webkit's npapi.h, add upload the patch to
bug#40785
Does that sound right ?
Sriram Neelakandan
Comment 12
2012-04-23 00:28:22 PDT
I guess this can be marked dup of
https://bugs.webkit.org/show_bug.cgi?id=40785
Martin Robinson
Comment 13
2015-05-07 16:31:26 PDT
I don't think we are interested in DirectFB any longer, but Wayland support is still an issue. *** This bug has been marked as a duplicate of
bug 81456
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug