Sprints are SCRUM. You don't need to use SCRUM to perform agile project management.
User stories are an attempt to dress up requirements gathering and the requirements traceability matrix. In project management, a requirement has a business justification and a stakeholder. The Requirements Traceability Matrix (RTM) will tell you the requirement (what?), the stakeholder (who?), the business justification (why?), and the Work Breakdown Structure (WBS) elements which implement the requirement (how?). User stories attempt to make this relatable by describing it in child-friendly terms: "As the manager of finances, I want to be able to compare categorized expenses from different time periods so that I can identify where our major expenses are and how new controls impact those expenses."
As you point out, this is kind of silly for an OpenGL back-end. The user story is something like "as a user on an operating system which doesn't support DirectX, I want to be able to use the software so that I can use the software," or something equally generic. In a RTM, you would simply identify stakeholders as "Linux users" and "MacOSX users", and give the business justification that "the software platform does not support the DirectX back-end". In an actual business, you might identify the product manager as the stakeholder, and use the business justification that demographic data shows interest among MacOSX users. There's no need to invent a fancy story.
If I had a client that would request a demo every 2 weeks I'd have been fired long ago.
If something deliverable can't be produced in 2 weeks, then it can't be delivered every 2 weeks. Plain and simple. Sometimes the next iteration or incremental deliverable takes months to ship. Nobody who knows what they're doing actually implements a 2-week rule; some people use that as a soft guide-line to wring out the WBS (which is used in SCRUM and other agile methodologies), and even then they find that some work packages are necessarily hours or days long while others take longer than 2 weeks.
The standard delineation for work packages is "when the work is broken down to a level at which further decomposition no longer provides a management benefit," which effectively means you only decompose work which cannot be fully understood and measured as a whole unit. "Actigraphy Module" for a generic polysomnography application, for example, is insufficient: you have to break that down at least to include Interfaces, Base Classes, Zero Crossing Class, Time Above Threshold Class, and Digital Integration Class. You might also include, at that level, an Integrations deliverable, which breaks down to include FitBit, Pillow, EightSleep, Jawbone, and other actigraphy-based systems, because "Integrations" is made up of complex pieces and can't be estimated without thinking about the pieces from which it's made.
None of that comes out to "two-weeks". It still comes out to iterative and incremental delivery, user feedback, and compiling lessons learned repeatedly to avoid further defects.