r...@vger.kernel.org and
subject:PATCH
96904
OTOH LKML is already a firehose that's impossible to drink from, so not
much difference there...
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On Thu, 19 Sep 2019, Geert Uytterhoeven wrote:
> Hi Jani,
>
> On Thu, Sep 19, 2019 at 10:49 AM Jani Nikula wrote:
>> On Thu, 19 Sep 2019, Geert Uytterhoeven wrote:
>> > On Thu, Sep 19, 2019 at 8:57 AM Dan Carpenter
>> > wrote:
>> >> On Wed, Sep
you the
initial list that's easy to trim.
BR,
Jani.
[1] https://gitlab.freedesktop.org/drm/maintainer-tools/blob/master/dim#L2398
--
Jani Nikula, Intel Open Source Graphics Center
ources. Do we expect them all to be up-to-date
too?
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
? do_init_module+0x27/0x209
> [ 43.306842] do_init_module+0x5f/0x209
> [ 43.310269] load_module+0x1987/0x1f10
> [ 43.313704] ? ima_post_read_file+0x96/0xa0
> [ 43.317174] SYSC_finit_module+0xfc/0x120
> [ 43.320754] ? SYSC_finit_module+0xfc/0x120
> [ 43.324065] SyS_finit_module+0xe/0x10
> [ 43.327387] do_syscall_64+0x73/0x130
> [ 43.330909] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [ 43.334305] RIP: 0033:0x7fd2d880b839
> [ 43.337810] RSP: 002b:7ffe0a6b2368 EFLAGS: 0246 ORIG_RAX:
> 0139
> [ 43.341259] RAX: ffda RBX: 55cdd86542e0 RCX:
> 7fd2d880b839
> [ 43.344613] RDX: RSI: 7fd2d84ea0e5 RDI:
> 0016
> [ 43.347962] RBP: 7fd2d84ea0e5 R08: R09:
> 7ffe0a6b2480
> [ 43.351456] R10: 0016 R11: 0246 R12:
>
> [ 43.354845] R13: 55cdd8688930 R14: 0002 R15:
> 55cdd86542e0
> [ 43.358224] Code: c7 05 ad 12 02 00 00 00 00 00 48 8d 88 00 08 00 00
> eb 09 48 83 c0 08 48 39 c1 74 31 48 8b 10 48 85 d2 74 ef 49 8b b7 98 04
> 00 00 <48> 39 b2 98 04 00 00 75 df 48 63 92 f8 04 00 00 f0 48 0f ab 15
> [ 43.361764] RIP: __video_register_device+0x1cc/0x1090 [videodev] RSP:
> a5c5c231b420
> [ 43.365281] CR2: 0499
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
ally, there are a few minor nitpicks on this patch.
> See below.
>
> The remaining patches looked ok on my eyes.
>
> I'll wait for a v3 with the debugfs ABI documentation in order to merge
> it. Feel free to put it on a separate patch.
debugfs ABI? Sounds like an oxymoron to
,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
gt;
> Well... I admit I've only really looked at the patches that impact
> backlight but dispersing this really odd looking bit twiddling
> throughout the kernel doesn't strike me a great API design.
>
> IMHO callers should not be required to find the first set bit in
> some specially crafted set of capability bits simply to get sane
> default behaviour.
Agreed. IMHO the regular use case becomes rather tedious, ugly, and
error prone.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
port;
> } channel[2];
Perhaps it would be slightly more elegant to be able to leave out
"channel." here and deduce that from the context... but the above
matches what you'd write in the higher level struct comment, and
produces the same output. It works and it's really simple. I like it.
Please submit this as a proper patch, with
Tested-by: Jani Nikula
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
}
> + foreach my $name (split /,/, $names) {
> + $name =~ s/^\s*\**(\S+)\s*/$1/;
> + next if (($name =~ m/^\s*$/));
> + if ($id =~ m/^\s*$/) {
> + # anonymous struct/union
> + $newmember .= "$type
> $name; ";
> + } else {
> + $newmember .= "$type
> $id.$name; ";
> + }
> }
> }
> }
> - $members =~
> s/(struct|union)([^{};]+){([^{}]*)}([^{}\;]*)\;/$newmember/;
> - $cont = 1;
> - };
> - };
> + }
> + $members =~
> s/(struct|union)([^\{\};]+)\{([^\{\}]*)}([^\{\}\;]*)\;/$newmember/;
> + }
>
> # Ignore other nested elements, like enums
> $members =~ s/({[^\{\}]*})//g;
--
Jani Nikula, Intel Open Source Technology Center
On Tue, 19 Dec 2017, Joe Perches wrote:
> drivers/gpu/drm/i915/i915_sysfs.c | 12 ++--
For i915,
Acked-by: Jani Nikula
--
Jani Nikula, Intel Open Source Technology Center
not much sense on outputting
> on a different text format.
>
> After this patch, only man and rst output formats are
> supported.
FWIW,
Acked-by: Jani Nikula
Please do keep at least two output formats going forward. Otherwise the
mechanisms of having more than one output format wi
On Thu, 31 Aug 2017, Randy Dunlap wrote:
> On 08/31/17 09:36, Jani Nikula wrote:
>> On Thu, 31 Aug 2017, Jani Nikula wrote:
>>> On Thu, 31 Aug 2017, Randy Dunlap wrote:
>>>> On 08/31/17 07:17, Jonathan Corbet wrote:
>>>>> On Thu, 31 Aug 2017 10:5
On Thu, 31 Aug 2017, Jani Nikula wrote:
> On Thu, 31 Aug 2017, Randy Dunlap wrote:
>> On 08/31/17 07:17, Jonathan Corbet wrote:
>>> On Thu, 31 Aug 2017 10:56:26 -0300
>>> Mauro Carvalho Chehab wrote:
>>>
>>>> It should have something to do with p
F-8 LANG in both python 2 and 3 compatible
ways.
The odd thing is that I can reproduce the issue using a small python
snippet, but not through Sphinx.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
that has nothing to do with python I/O, and everything to do with
the encoding of that specific python source file.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
SVGA3dCmdHeader *header)
> {
> - return capable(CAP_SYS_ADMIN) ? : -EINVAL;
> + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL;
> }
>
> static int vmw_cmd_ok(struct vmw_private *dev_priv,
--
Jani Nikula, Intel Open Source Technology Center
rking on the NUC, because
> then you have native CEC support without requiring any Pulse Eight adapter.
>
> And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C
> output as well.
>
> Regards,
>
> Hans
--
Jani Nikula, Intel Open Source Technology Center
pcd_writeb(&intel_dp->aux,
> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> + cec_irq);
> + if (ret < 0)
> + return handled;
> + }
DP sinks suck. Please add a limit to the loop.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Thu, 25 May 2017, Hans Verkuil wrote:
> From: Clint Taylor
>
> Adding DPCD register definitions from the DP 1.3 specification for CEC
> over AUX support.
>
> V2: Add DP_ prefix to all defines.
> V3: missed prefixes from the ESI1 defines
>
> Cc: Jani Nikula
&
exit
> +fi
> +
> +DIR=$(dirname $0)
>
> in=$1
> rst=$2
> tmp=$rst.tmp
>
> cp $in $tmp
> -sed --in-place -f convert_template.sed $tmp
> +sed --in-place -f $DIR/convert_template.sed $tmp
> pandoc -s -S -f docbook -t rst -o $rst $tmp
> -sed --in-place -f post_convert.sed $rst
> +sed --in-place -f $DIR/post_convert.sed $rst
> rm $tmp
> +echo "book writen to $rst"
--
Jani Nikula, Intel Open Source Technology Center
I'm in favor of just bulk converting the rest of
the .tmpl files using Documentation/sphinx/tmplcvt, get rid of DocBook
and be done with it, and have the crowds focus on rst.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Thu, 30 Mar 2017, Jani Nikula wrote:
> On Wed, 29 Mar 2017, Mauro Carvalho Chehab wrote:
>> The pandoc conversion is not perfect. Do handwork in order to:
>>
>> - add a title to this chapter;
>> - use the proper warning and note markups;
>> - use kernel-d
==
>
> @@ -475,7 +496,7 @@ can also benefit non-OTG products.
> - Also on the host side, a driver must support the OTG "Targeted
> Peripheral List". That's just a whitelist, used to reject peripherals
> not supported with a given Linux OTG host. *This whitelist is
> - product-specific; each product must modify ``otg_whitelist.h`` to
> + product-specific; each product must modify* ``otg_whitelist.h`` *to
> match its interoperability specification.*
>
> Non-OTG Linux hosts, like PCs and workstations, normally have some
--
Jani Nikula, Intel Open Source Technology Center
doing this stuff in Sphinx, with Sphinx extensions. And
to me it sounds like what you describe is interesting outside of kernel
too.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
th
;re
seasoned kernel developers or newcomers purely interested in
documentation.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
all the .gif and .png files to .pnm. This would
> make the files patchable but also add around 25MB to the uncompressed
> kernel source tree (118kb compressed, compared to 113kb for the .gif and
> .png files). This is certainly worse than the uuencoded files you
> had before
>
>
On Thu, 10 Nov 2016, Jani Nikula wrote:
> On Thu, 10 Nov 2016, Markus Heiser wrote:
>> Could this POC persuade you, if so, I send a more elaborate RFC,
>> what do you think about?
>
> Sorry, I do not wish to be part of this.
That was uncalled for, apologies.
Like I said,
On Thu, 10 Nov 2016, Markus Heiser wrote:
> Could this POC persuade you, if so, I send a more elaborate RFC,
> what do you think about?
Sorry, I do not wish to be part of this.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send th
On Wed, 09 Nov 2016, Markus Heiser wrote:
> Am 09.11.2016 um 12:16 schrieb Jani Nikula :
>>> So I vote for :
>>>
>>>> 1) copy (or symlink) all rst files to Documentation/output (or to the
>>>> build dir specified via O= directive) and generate the
On Wed, 09 Nov 2016, Mauro Carvalho Chehab wrote:
> Em Wed, 09 Nov 2016 13:16:55 +0200
> Jani Nikula escreveu:
>
>> >> 1) copy (or symlink) all rst files to Documentation/output (or to the
>> >> build dir specified via O= directive) and generate the *.pd
t...
> IMO placing 'sourcedir' to O= is more sane since this marries the
> Linux Makefile concept (relative to $PWD) with the sphinx concept
> (in or below 'sourcedir').
>
>
> -- Markus --
>
>
> --
> To unsubscribe from this list: send the line &qu
the correct fix is to have this fixed in upstream Sphinx, but
as a workaround an extension doing the above seems plausible, and not
too much effort - provided that we can make the raw latex work.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 02 Nov 2016, Markus Heiser wrote:
> Am 02.11.2016 um 12:43 schrieb Jani Nikula :
>
>> On Wed, 24 Aug 2016, Markus Heiser wrote:
>>> From: Markus Heiser
>>>
>>> This extends the method to build only sub-folders to the targets
>>> "lat
loop_cmd,sphinx,latex,$(var),latex,$(var)))
> endif # HAVE_PDFLATEX
>
> pdfdocs: latexdocs
> ifneq ($(HAVE_PDFLATEX),0)
> - $(Q)$(MAKE) PDFLATEX=xelatex LATEXOPTS="-interaction=nonstopmode" -C
> $(BUILDDIR)/latex
> + $(foreach var,$(SPHINXDIRS), $(MA
On Thu, 27 Oct 2016, Markus Heiser wrote:
> Hi Jani,
>
> Am 24.10.2016 um 11:04 schrieb Jani Nikula :
>
>> I think I saw some of this in the past [1], but then couldn't reproduce
>> it after all. Now I'm seeing it again. Sporadically
>> Documentation/me
t; htmldocs' attached for both cases.
Using Sphinx (sphinx-build) 1.4.6
BR,
Jani.
[1] id:8760rbp8zh....@intel.com
--
Jani Nikula, Intel Open Source Technology Center
SPHINX htmldocs --> file:///home/jani/src/linux/Documentation/output;
make[2]: Nothing to be done for 'all&#x
e hard of thinking, this list is meant to remain in alphabetical
> -order. If you could add yourselves to it in alphabetical order that would be
> -so much easier [Ed]
> +======= =
> +``K:`` ``of_get_profile``matches patches or files
> + that contain
> +
On Tue, 11 Oct 2016, Markus Heiser wrote:
> Anyway, these are only my 2cent. I'am interested in what Jon says
> in general about using (Perl) scripts to generate reST content.
I think I've said all that I have to say on the subject. Up to Jon.
BR,
Jani.
--
Jani Nikula, I
On Tue, 11 Oct 2016, Mauro Carvalho Chehab wrote:
> Em Tue, 11 Oct 2016 09:26:48 +0200
> Markus Heiser escreveu:
>
>> Am 07.10.2016 um 07:56 schrieb Jani Nikula :
>>
>> > On Thu, 06 Oct 2016, Mauro Carvalho Chehab wrote:
>> >> Em Thu, 06 Oct 2016
On Thu, 06 Oct 2016, Mauro Carvalho Chehab wrote:
> Em Thu, 06 Oct 2016 17:21:36 +0300
> Jani Nikula escreveu:
>> We've seen what happens when we make it easy to add random scripts to
>> build documentation. We've worked hard to get rid of that. In my books,
>>
On Thu, 06 Oct 2016, Mauro Carvalho Chehab wrote:
> Em Thu, 06 Oct 2016 11:42:14 +0300
> Jani Nikula escreveu:
> Just curious here: what use case do you see by building the Kernel
> documentation without the Kernel tree?
Not without the kernel tree, but without the kernel buil
build became so unwieldy was the
proliferation of arbitrary scripts and tools required to make it
happen. I think it would be really sad to let this happen to the Sphinx
build. I am *already* sad about how parse-headers.pl was bolted on to
the build.
BR,
Jani.
--
Jani Nikula, Intel Open Source
On Wed, 05 Oct 2016, Daniel Vetter wrote:
> Jani Nikula has a patch with a scrip to make the one kernel-doc parser
> into a lint/checker pass over the entire kernel. I think that'd would
> be more robust instead of trying to approximate the real kerneldoc
> parser. Otoh that p
>
> Did you want maybe:
>
> if major == 1 and minor < 4:
>
> ?
>
> (That will fail on 0.x, but we've already stated that we don't support
> below 1.2).
Is there a way to check the number of entries expected in the tuples
instead of trying to
d some -j by
default?
BR,
Jani.
[1]
http://www.sphinx-doc.org/en/stable/invocation.html#invocation-of-sphinx-build
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
as function, not as macro).
>From an API user's perspective, functions and function-like macros
should work interchangeably. Personally, I don't think there needs to be
a difference in the index. This seems to be the approach taken in
Sphinx, but it just doesn't work well for automati
ion when the number of arguments is zero, but, on such case,
> it doesn't really matter.
What does Sphinx say if you add "void" as the type? Or a fake
"macroparam" type?
If those hacks don't help, Mauro's suggestion seems sane.
BR,
Jani.
>
> Thanks,
&
On Mon, 22 Aug 2016, Markus Heiser wrote:
> Am 22.08.2016 um 13:16 schrieb Jani Nikula :
>
>> On Mon, 22 Aug 2016, Mauro Carvalho Chehab wrote:
>>> Markus,
>>>
>>> Em Mon, 22 Aug 2016 10:56:01 +0200
>>> Markus Heiser escreveu:
>>>
> would be expecting, instead, the weird syntax:
>
>.. c:member:: int (*) (struct v4l2_subdev *sd, u8 *buf, size_t
> count,ssize_t *num) rx_read
>
> With hurts my eyes.
>
> As I guess we don't want to maintain ourselves a LaTeX output Sphinx
> plugin forke
the same level in that regard. You're suggesting to
make html the root of everything?
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
at we want.
> doc-rst: parseheaders directive (inital)
I think this patch will break bisect, because it changes the perl script
before its users are converted.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux
dits.
BR,
Jani.
PS. I am no saint here, I've got a couple of authors lines myself. I
promise not to add more. I certainly won't chastise anyone for adding
theirs.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "un
few lines what you want to
achieve? I can guess based on the current solution, but I'd like to hear
it from you. Please leave out rants about tools and languages etc. so we
can focus on the problem statement, and try to figure out the best
overall solution.
Thanks,
Jani.
--
Jani Nikula, Int
On Wed, 10 Aug 2016, Mauro Carvalho Chehab wrote:
> Em Mon, 08 Aug 2016 18:37:38 +0300
> Jani Nikula escreveu:
>
>> Hi Mauro & co -
>>
>> I just noticed running 'make htmldocs' rebuilds parts of media docs
>> every time on repeated runs. This
On Mon, 08 Aug 2016, Markus Heiser wrote:
> Hi Jani,
>
> Am 08.08.2016 um 17:37 schrieb Jani Nikula :
>
>>
>> Hi Mauro & co -
>>
>> I just noticed running 'make htmldocs' rebuilds parts of media docs
>> every time on repeated runs. This
On Mon, 08 Aug 2016, Jani Nikula wrote:
> I wonder if it's related to Documentation/media/Makefile... which I have
> to say I am not impressed by. I was really hoping we could build all the
> documentation by standalone sphinx-build invocation too, relying only on
> the conf.py
tion file extends (or overwrites)
> the
> +configuration values from the origin ``conf.py``. With this you are
> able to
> +maintain *build themes*. """
> +
> +config_file = os.environ.get("SPHINX_CONF", None)
> +if config_file is not None and o
in
commit 547218864afb2745d9d137f005f3380ef96b26ab
Author: Mauro Carvalho Chehab
Date: Sat Jul 9 13:12:45 2016 -0300
doc-rst: add an option to ignore DocBooks when generating docs
and aligns with
commit 6387872c86ea6698ed8faa3ccad1d1bd60f762f7
Author: Jani Nikula
Date: Fri Jul 1 15:24:44
past six months,
I never would have guessed media docs would be among the first docbooks
converted. Fantastic job!
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to m
On Fri, 06 May 2016, Markus Heiser wrote:
> Am 06.05.2016 um 17:06 schrieb Jani Nikula :
>
>> On Fri, 06 May 2016, Markus Heiser wrote:
>>> @Jonathan: what do you think? Should I prepare a patch
>>> with a basic reST (sphinx) build infrastructure, including
>&
se Sphinx, and will expect to find the good old
plain text files (albeit with some markup) where they always were.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to m
lude the kernel-doc extension in the
kernel source tree? Having things just work if sphinx is installed is
preferred over requiring installation of something extra from pypi. (I
know this may sound backwards for a lot of projects, but for kernel I'm
pretty sure this is how it should be done.)
BR,
;s hackish at best and needs a lot of cleaning up. It's a proof of
> concept, but it's hardly finished (one might say it's barely begun...)
Thanks. I'll start looking at how to make it less hackish and more
upstreamable.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology
round. Instead of
gradually fixing things, we'll end up gradually messing things up even
more.
For those specific examples, IIRC the last time I played with that,
simply leaving the prefix whitespace in place went a long way (just eat
" * " from the lines). The asciiart just worked.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ally, do not attempt to detect and
parse elements like lists in kernel-doc.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
e outlier, when there's a better
alternative for the vast majority of the documentation. Especially when
Asciidoctor isn't a ready solution for media documentation either.
In summary, my proposal is to go with Sphinx, leave media docs as
DocBook for now, and see if and how they can be con
On Wed, 09 Mar 2016, Dan Allen wrote:
> On Tue, Mar 8, 2016 at 6:58 AM, Jani Nikula wrote:
>
>> I need to look into this again. Is there a specific option or directive
>> to produce split output for includes? When I tried this, the result was
>> just one big output fil
between Sphinx and Asciidoctor, not so
much doc vs. doctor. The native output format and extension support in
Sphinx is appealing; I am not yet convinced we could manage with
Asciidoctor but without DocBook. The extension offering seems better in
Sphinx.
> Whatever you decide, I wish you a
, so much so that it becomes part of the
normal checks for patch inclusion.
BR,
Jani.
[1] http://mid.gmane.org/86pow31ddj@hiro.keithp.com
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of
f we end up having to modify Sphinx, it has a powerful extension
mechanism for this. We wouldn't have to worry about getting it merged to
Sphinx upstream, and we wouldn't have to carry a local version of all of
Sphinx. (In fact, the extension mechanism provides a future path for
doing kern
doctor is
> I believe the standard bearer for ASCIIdoc these days, albeit called
> ASCIIdoctor.
If we're talking about the same asciidoctor (http://asciidoctor.org/)
it's written in ruby but you can apparently run it in JVM using
JRuby. Calling it Java-based is misleading.
BR,
Jani.
a roll of dice, err, a well-thought-out decision
from the maintainer to go with one or the other, so we can make some
real progress.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the bod
t; depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> depends on HAS_DMA
> + depends on OMAP_IOMMU
> select ARM_DMA_USE_IOMMU
> - select OMAP_IOMMU
> select VIDEOBUF2_DMA_CONTIG
> ---help---
>
On Thu, 10 Jan 2013, Inki Dae wrote:
> 2013/1/10 Laurent Pinchart :
>> Hi Vikas,
>>
>> Thank you for the patch.
>>
>> On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote:
>>> On 3 January 2013 16:29, Tomasz Figa wrote:
>>> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
>>> >>
Hi Laurent -
On Tue, 18 Dec 2012, Laurent Pinchart wrote:
> Hi Jani,
>
> On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
>> I can see the need for a framework for DSI panels and such (in fact Tomi
>> and I have talked about it like 2-3 years ago already!) but wha
Hi Laurent -
On Mon, 17 Dec 2012, Laurent Pinchart wrote:
> Hi Tomi,
>
> I finally have time to work on a v3 :-)
>
> On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
>> On 2012-11-22 23:45, Laurent Pinchart wrote:
>> > From: Laurent Pinchart
>> >
>> > Hi everybody,
>> >
>> > Here's t
77 matches
Mail list logo
