Related
In last couple months while learning to develop Java Card applets I managed to develop ISO 7816 compatible file system applet. I successfully implemented most of the standardized APDU commands from 7816-4, -8, -9 standards (I used other available functional descriptions and standards like OpenPGP applet, IAS ECC, MUSCLE, CoolKey etc. to help me understand former standards).
Now I am trying to develop PKCS#11 implementation for this my own applet. I am familiar with using OpenSC tools for already supported cards (opensc-tool, opensc-explorer, pkcs15-init, pkcs15-tool etc.). But I would like to develop driver for this applet for OpenSC.
I browsed information available on their project site on github and found some documentation on implementing custom driver for OpenSC (entersafe card example, and general suggestions for card driver implementation). Also I found that on gooze.eu there were available some tutorials on OpenSC, but this site is no longer available.
So my questions are:
Where can I find some more information on OpenSC API in order to understand available driver code and to manage to develop my own?
Any general overview of API, about OpenSC architecture, description of available functions (description on intended usage of structures and functions such as sc_format_apdu, sc_transpit_apdu, sc_card_operatins as an example etc.) to give me a jumpstart for understanding OpenSC source code and implementing a card driver.
Are there any man pages for OpenSC API (googling I was able to find some, but very incomplete and sporadic).
Any information would be very helpful.
Why don't you either use IsoApplet (that has both JavaCard applet and OpenSC driver) or if you want to develop your own, learn from its source code.
Also, if you have studied the standards and existing applets (and drivers) you should have enough domain knowledge to get an idea of what some of the API functions do. If not, keep your code somewhere in public and you can (hopefully) get support from the OpenSC developers via mailing list.
Upon considering the driver side implementation for DirectX API on windows systems for modern video cards I was wondering why this implementation is not available on non-windows system, most notably linux.
Since there is an obvious absence of this functionality I can only assume there is a good reason which I am blind to, but in my primitive understanding I simply see the DirectX calls as no more than function entry points on the hardware device. And for the record I am not referring to a compatibility layer (most notably WINE, a project I am amazed by every single day) but a library making direct hardware calls.
Is it possible to create an open source version of directx? Would it be possible but obscenely difficult?
AFAIK, the DirectX contains 3 parts
Vendor driver (provide low level API defined by DX)
DirectX library (use low level API defined by DX to access hardware, provide DirectX API)
Software (use DirectX API, ex. game)
There are no driver providing the low level API defined by DX on linux, so even it is possible to provide the DirectX library, but it won't work without proper vendor driver, and I can't see if there is any vendor is going to create one for their hardware platform.
Why not just use OpenGL? It supports all the functionality that DirectX does. Do you have a specific reason to use DirectX? As for a reason, Microsoft made DirectX and I guess they didn't see any need to allow it to run on Linux.
You can run DirectX games in Linux using Wine. You can program XNA on Linux using MonoGame. But all of these use OpenGL to provide hardware-accelerated rendering. AFAIK, OpenGL has been (and probably will be) the only option on Linux for the foreseeable future.
Is it possible to write your own DirectX implementation? Sure - but it involves writing drivers, proprietary knowledge and probably too much cost for anyone to REALLY benefit from it.
EDIT: These days, DXVK is a very real and performant way to run DirectX applications on Linux.
DirectX is a suit of API's:
Direct3D (drawing 3D graphics)
DirectX Graphics Infrastructure (enumerating adapters and monitors and managing swap chains)
Direct2D (drawing 2D graphics)
DirectWrite (fonts)
DirectCompute (GPU Computing)
DirectSound3D (playback of 3D sounds)
DirectX Media (DirectAnimation for 2D/3D web animation, DirectShow for multimedia playback and streaming media, DirectX Transform for web interactivity, and Direct3D Retained Mode for higher level 3D graphics)
DirectX Diagnostics (tool for diagnosing and generating reports on components related to DirectX, such as audio, video, and input drivers)
DirectX Media Objects (support for streaming objects such as encoders, decoders, and effects)
DirectSetup (installation of DirectX components, and the detection of the current DirectX version)
DirectX components deprecated, but still supported
DirectDraw
DirectInput
DirectPlay
DirectSound
DirectMusic
As you can see many parts of the DirectX suit of API's would need to be rewritten with functionality for Drivers written for Linux. Also some parts of the DirectX suit are likely going to make calls to the Windows OS and that code would have to rewritten for a Linux machine without infringement of the copy-written parts of either DirectX or the Windows OS.
Yes you could write a open source API suit which does the same kind of thing as DirectX for Linux, however without a great knowledge of sound and graphic drivers/support by their manufactures for Linux, it would be a very hard task to do.
However if you question was more of a "Can I get/write something to be able to run games and programs made with DirectX to run on Linux?" in it's meaning, in short no due to more likely copyright infringement.
Your question is wrong in 2019. DXVK is an implementation of D3D11 and D3D10 implementation for Linux using Vulkan and Wine
Also mesa has native Direct3D 9 implementation but in my knowledge, no one uses it except wine
The work to create a port for DirectX would create the same problems as you encounter in WINE. It will never be the same as on Windows. Derived from that principle you would have to look into OpenGL and related multi-platform libraries.
At this very moment WINE would be your closest medium if you want to accomplish something with DirectX code you already have. Then again, I'm not sure in what manner Visual Studio or plain typing would get you closer yo a fluent environment. The WINE libraries aren't that far from native, but there always exists emulation, what is acceptable to a certain point in my honest opinion.
If I look at how superbly Final Fantasy XIV ran on full settings on my iMac (2011) I think it's not that bad to rely on WINE's implementation. The game exactly rendered as on Bootcamp (Windows) on my iMac.
If you really want to make work on this front you could try to ask WINE Devs at their forums or mailing lists how you could maybe use the implementation of their DirectX compatibility only and use that in your project. Where you maybe can call libraries instead of requesting DirectX through Windows-emulated system calls.
Edit: I fully agree with user956030's answer too.
DirectX is a propriety products designed for Microsoft targets, so for this to happen would be very unusual
There are two other pieces of software that come to mind, SDL and OpenGL
OpenGL provides the hardware alternative to DirectX, and SDL works with OpenGL to provide the software support you would expect from DirectX
Since 2020, Microsoft has been working to port DirectX 12 to WSL2, which is being done in this repository. In a mailist, Steve Pronovost commented that they might work to port this driver to Linux to have it running natively.
However, in order to do this, they would need to implement the driver on top of the kernel's DRM stack, which itself needs to be modified if they want to keep the driver similar to the Windows one and have related APIs.
There is some effort being done in the Mesa library as well, to support D3D12 within itself, the main purpose being to optimize server-sided GPU calculations that are heavily used in machine learning algorithms.
Even though this is great, it's unlikely that we will ever see any advantage running Windows games on Linux with that driver. The open source community would only have the upper ground if more games start supporting Vulkan, which is faster and better than DirectX, there had been experiments where using DXVK on Windows would be faster than DirectX 9 or even 11, such as the one mentioned here, but DXVK tends to be less reliable and more prone to errors and crashes.
My team is tasked with building a full screen, kiosk-style application for playing back media files. Initially we need to support WMV / MP4 as well as some images in full 1080p, although down the line we will need to extend this to cover other formats (different videos formats as well as display of HTML, SWF, etc).
The application also contains a decent chunk of business logic relating to scheduling, logging, performance monitoring as well as network code to talk to a central server through web services (or maybe TCP) and potentially act as a server itself.
For our WMV / MP4 video playback, hardware acceleration will be a massive bonus. The targetted hardware has weak CPUs but strong graphics cards.
Here's the kicker: we're a .NET shop (our existing application is a WinForms smart client) and extremely experienced and productive in C# and the .NET stack. The app will initially be targetting Windows Embedded (.NET 3.0), but we will quickly need a Linux version as well. Between us we have some C/C++ experience and some Linux experience but we do not anticipate good productivity on that platform.
So I am soliciting recommendations specfically on the following points:
Video. On Windows we have seen good success using DirectShow.NET. On capable hardware, the WPF MediaElement also seems to perform well. What should we be using on Linux? libavcodec seems like a common choice. Is it hardware accelerated on NVidia graphics cards on Linux? What other options do we have on Linux? Is there something cross-platform that I could consider?
Stack.
a) Ideally we could write the whole thing in .NET and then run under Mono on Linux. The video playback and presumably some other components (like performance monitoring) would not be supported on Mono. I guess we could rewrite these elements in, say, C++; but I'm guessing that most stuff on the business logic side would work.
b) Maybe it's better to forfeit our up-front productivity on the Windows version for something that's cross platform out of the gate. What about Java? Do we have different options when it comes to video there? How about another framework? Something like QT? Can anyone else suggest something cross platform that would be relevant?
Broadly speaking, given the requirements, what would you use?
I appreciate any anwsers you might have.
My suggestion is that you use Fluendo's GStreamer components for the video playback as it has support for hardware acceleration where available and fully licensed codecs.
You can look at the Banshee media player which support video playback if you have the Fluendo/GStreamer packages installed. Get OpenSUSE 11.2 which contains everything you need to try it and develop, and then buy and install the Fluendo codecs.
Source code wise, Banshee does the video display from C#, look here:
The C# source code consuming GStreamer and doing the video rendering is here:
http://git.gnome.org/browse/banshee/tree/src/Extensions/Banshee.NowPlaying/Banshee.NowPlaying
The C supporting library to call into Fluendo is available here:
http://git.gnome.org/browse/banshee/tree/libbanshee
For testing Banshee, you do not need to buy anything, but your video codecs will be limited to Ogg/Theora encoded videos. Once you get Fluendo's codecs you will be able to play WMV files.
One option would be to use Silverlight, and explore Moonlight as an option for the linux version. My understanding is that Moonlight has several media/codec plugins (I believe ffmpeg is the main provider) and can additionally use the MS codec pack to give you support for things like WMV/MP4.
You can use ffmpeg in mono and .net. This may or may not include video display - ffmpeg usually just provides you with a decoded bitmap that you can do whatever you want with, be it display it in a window, save it in a file, whatever. If you use ffmpeg-sharp the same code should work on Windows or Linux. Really, putting the bitmap in a window is the easy part.
Moonlight offers two codecs: (a) A fully licensed version that comes straight from Microsoft and requires no further negotiation with the MPEG-LA and other patent holders, or (b) an ffmpeg backend that requires you to negotiate with the patent stock holders if you plan on using.
You could build a Silverlight-based application, the trick to get access to the local system is very simple: you run a local web server that exposes those services.
You can still use C#/Sqlite or VistaDB as your storage system as part of your Silverlight application.
You could host the silverlight app in http://localhost/App.xap and this app would gain local access to the machine by contacting a REST or SOAP web service on http://localhost/rest.ashx or http://localhost/soap.asmx
For example, if you needed to read some values from a scanner connected to the machine, you would issue this request:
http://localhost/scanner.ashx?operation=scan_badge
Then your scanner.ashx HttpHandler will do the actual scanning (this one has full system rights) and return the value to the Silverlight application.
I'm getting started developing with OpenGL ES on ARM/Linux, and I would like to draw something full-screen but don't know where to start.
I'm not developping on iPhone, nor Android. This is a Linux/OpenGL ES question.
I know it's possible to draw on the framebuffer with OpenGL ES without any library but I don't find any resources about that topic, could you help me?
I don't have any code to show how to do it but basicly you use de framebuffer device as the target of OpenGL|ES operations.
Are you developing with an embedded platform as a target? If so, you could use software implementations on your host system and then the actual driver on the embedded device.
There is a small project for supporting OpenGLES 1.1 on linux called dlges. You could also try mesa.
I imagine that the driver itself might have a header for OpenGL that you could look at and see if it supports OpenGLES calls. Alternatively, you could set up function pointers to make your OpenGL Code look more like OpenGL ES.
Good luck!
Don't forget that desktop Linux comes with OpenGL, not OpenGLES! They're similar but not quite compatible. If you want to do work on OpenGLES on a desktop Linux platform, ARM or otherwise, you'll need an OpenGLES emulator library. Sorry, can't recommend any, I'm looking for one myself.
OpenGLES just handles the process of drawing stuff into the window. You also need a windowing library, which handles the process of creating a window to draw stuff into, and an event library, which deals with input events coming back from the window.
SDL will provide both of the last two, as will a bunch of other libraries. Khronos themselves have standardised on EGL as the windowing library and OpenKODE as the event library... but I don't actually know where to get open source implementations of these for Linux. (I work for a company that does EGL and OpenKODE for embedded platforms, so I've never needed to find an open source version!)
ARM offers few GPUs that support OpenGL 2.0. You can find some examples and and emulator that runs on linux on the Mali Developer site.
Of course that's mostly to target ARM GPUs, but I am pretty sure it could be used to examine OpenGL ES programming possibilities.
Here is a tutorial showing how to use SDL in combination with OpenGL ES. It's for the OpenPandora platform, but since that runs Linux, it should be applicable on the desktop if you can get the proper library versions.
Use of SDL is more or less standard with this kind of programming, in Linux. You can of course go the longer route and open the window yourself, attach a GL rendering context and so on, but usually it's easier to learn the relevant parts of SDL. That also gives you easy-to-use API:s for input reading, which is almost always necessary.
You can use PowerVR SDK for Linux http://community.imgtec.com/developers/powervr/graphics-sdk/
There are a lot of samples.
The main players seem to be x264, and xvid, and both are GPL. This means we can't integrate decoding capabilities into a playback application without licensing the whole thing as GPL, so we can't use either.
The preferred target platform is Linux. Any non-viral open license is fine, we're more than happy to provide the source of any changes we make to libraries, just not our whole application.
Is there anything? Or maybe we should use GPL for now as a test during development, and plan to replace it with commercially licensed codec before shipping?
The ffmpeg H.264 decoder is LGPL. Only the encoders are GPL, and x264 does not provide a decoder.
It also has the advantage over Framewave and IPP of actually being usable.
Cisco released a BSD-licensed h264 library for encoding and decoding.
I wish you would just use GPL, but I'm not going to just tell you to do that when there is an answer out there.
http://www.openh264.org/
and the GitHub page:
https://github.com/cisco/openh264
PocketVideo's OpenCore is now open-sourced under Apache 2.0 license as part of Android OS:
https://github.com/android/platform_external_opencore
IANAL, but if you're shipping anywhere software patents are enforced, not only do you have to pay the MPEG LA royalties for h.264 decoding, but the license might preclude you from using the open-source decoders anyhow. I've heard of similar annoyances applying to other codecs.
A project derived from AMD performance library, Framewave, now has a video component supporting h.264 decoding.
The license is the "Apache 2.0 license"
you can check it out at Sourceforge SVN
IANAL.
If you ship unmodified binaries created from unmodified GPL source and your application simply invokes them, I believe your entire app does not have to be GPL. You may have to include GPL documentation and/or the source of the bundled GPL apps, but if you are not making any modifications or linking against GPL code, your code should be unaffected.
As far as the MPEG standards, that may be another bag of worms entirely...
Ok, FFMpeg appears to handle h.264. I believe most of it is LGPL.
Would still love to hear experiences with it (good or bad), or other options, thanks.
--
Correction, the version I just tested appears to be compiled with "--enable-gpl", which leads me to beleive it's making use of GPL licensed codecs. Argh!
Take a look at the Intel IPP Libraries. They are not free, but are very cheap (a once-off payment of a hundred dollars or something). You can also get a free evaluation to test it out. The licence is very open, and as far as I know allows you unlimited distribution in your application forever once you buy it.
I've done some work with FFmpeg, though it was limited to libavformat (the codec part is called libavcodec). I found the API to be surprisingly straight forward and easy to use. They provide a few really useful and enlightening samples in the standard source distribution.
Generally the library holds rather high quality, but some modules seems to be lacking, so I can't vouch for the h264 part. I've heard good things about the encoder, though.
Note that VLC and most of its libraries are now LPGL
VLC engine relicensed to LGPL -
http://www.videolan.org/press/lgpl-libvlc.html
VLC playback modules relicensed to LGPL -
http://www.videolan.org/press/lgpl-modules.html