You don't send a huge patch to a project as a first time contributor.
I am sure sigrok would benefit from your improvements, but sometimes the maintainer has a busy life outside the project so you need to adapt to their pace, at least in the beginning.
I would agree without even the caveat of the maintainer being busy. When a maintainer receives a massive changeset they have to then recover why the task was taken on in the first place and understand any decisions to get to the same outcome presented in the changeset provided. The more logical complexity that this change represents whether it is 3 lines or 3000 lines still needs to be understood by the reviewer as not breaking the rest of the system and equally can be 'massive.' The further you get from an N+1 change into a N+5 or N+6 change is where you get into situations where a N+3 change is flawed based on the rest of the system and invalidates large parts of the changeset, and that doesn't resolve all the issues or concerns.
I think a lot of people forget that changesets are sometimes not the most straightforward way to express ideas. They (including myself) also forget that while you are working with a change in front of you it's obvious but in one month it could be opaque. A maintainer is often giving you the perspective of you a month later who built on this system you changed.
For something like drivers most of them are probably from first time contributors, and they aren't really going to be hanging around for further contributions.
That's fine - the driver would improve if the contributions are accepted, and they don't touch core code that will break other things. But instead totally non-functional drivers are left languishing because PRs aren't merged.
In the case of Sigrok the problem didn't seem so much the maintainers, but rather non-developers "triaging" PRs with unhelpful advice to split patches, when a lack of actual developers meant they'd never be looked at anyway. Otherwise a fork might have occurred rather than wasting everyone's time.
I wish projects would be more strategic around acceptance rates on drivers/plugins contra core. On plugins etc one should have much lower barriers to contributions, compared to on the core. It is actually one of the primary reasons why such architectures are beneficial in FOSS projects.
And sometimes the best way to contribute is by forking. Depends on the situation for sure, but this encourages an acceleration by the maintainers of the original library. If they don't have the time to do so, they can comfortably ignore the fork.
You don't send a huge patch to a project as a first time contributor.
I am sure sigrok would benefit from your improvements, but sometimes the maintainer has a busy life outside the project so you need to adapt to their pace, at least in the beginning.