Justin P. Mattock wrote:
*baffled* Why did you think that would work? transmit_cmd()s signature
has 4 parameters.
I have no manual in front of me. Did a quick google, but came up with
(no hits) info on what that function does. grep showed too many entries
to really see why/what this is.
Hello, new on list but not to the kernel. I also have the issue on
ThinkPad X40.
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated
Graphics Device (rev 02) (prog-if 00 [VGA controller])
Subsystem: IBM Device 0557
Flags: bus master, fast devsel, latency
Toralf Förster wrote:
today I run at the latest 2.6.35.6 kernel few apps like Lotus Notes
under wine,
I'm still stuck with 2.6.36-rc1, and both here and on many/most
earlier kernels I get a few seconds of very irritating stuttering
whenever I run wine. It is definately related to interaction
Chris Wilson wrote:
a few seconds of very irritating stuttering whenever I run wine.
i915
wine triggers an xrandr storm for its own unknown reasons.
Same underlying reason as for the 600ms keyboard pauses I saw.
One #winehq person claims that ATI and NV drivers track monitor
state and
Peter Stuge wrote:
I hope it can be resolved.
There was talk about knobs. Maybe a simple kill switch for VGA1? I
want my machine to require explicit enable of VGA1 before it will
be used anyway. A disable knob would work great for me. :)
//Peter
Keith Packard wrote:
This connects the kernel uevent indicating monitor hotplugging to the
RandR notification events so that X applications can be notified
automatically when monitors are connected or disconnected.
Are these events actually being generated?
If there is the infrastructure to
Russell King - ARM Linux wrote:
I feel it would be better to allow the current situation to continue.
I think this misses the point, and is somewhat redundant; I think
everyone knows that it is easiest to never change anything. But
then nothing improves.
If we start telling people that they
Jesse Barnes wrote:
An alternative to fixing grub would be to add aliases like you mention,
and/or change the parser to accept _ as an alias for . Then we
could leave the sysfs values and string table alone.
Is it already case insensitive?
//Peter
Sergej Pupykin wrote:
And it's ugly; can't we fix grub instead?
I am searching for bootloader which can pass whitespaces. It looks
like we should patch grub-legacy (0.97), grub (1.98) and lilo...
(I did not try lilo yet, but man page says nothing about passing
spaces in 'append=' option
Linus Torvalds wrote:
You should always take for granted that the BIOS is wrong.
Better yet, that there is no BIOS. Maybe one happy day, in the future.
//Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Indan Zupancic wrote:
Confirm I also have this issue on my X40, but there are other bugs
that are much more significant so I haven't bothered mentioning this.
What issues?
The one I confirmed is corrupted graphics within Gecko. I haven't had
Xv working for a long time either. Not sure if
Indan Zupancic wrote:
What I don't understand is how BIOS makers could know about those bits.
They have relationships with Intel since 30 years, ie. they get what
they need in one form or other.
//Peter
___
dri-devel mailing list
Indan Zupancic wrote:
Everything would be a lot simpler if the BIOSes were open source.
coreboot has existed for about eleven years and some 250 mainboards of
varying shapes and sizes (from laptop to server) are supported, but it's
only just recently that things are really taking off, with the
Michel Dänzer wrote:
You won't have any trouble finding plenty of examples of newcomers
having a better experience, as most of them thankfully don't come in
with such a bad attitude and conduct.
To a bystander it would seem that Ilija has great attitude and conduct.
//Peter
Norbert Preining wrote:
Do you see what scrolls by above the text you took a picture of
More than what I can see on the screen shot I cannot grasp.
Maybe try serial console, netconsole or usb debug device.
//Peter
___
dri-devel mailing list
Daniel Vetter wrote:
> Please provide the usual details about your system (especially what gpu
> this is on). Also, screenshots of what typical corruptions look like can
> help a lot in tracking down such things.
Confirm I also have this issue on my X40, but there are other bugs
that are much
Indan Zupancic wrote:
> > Confirm I also have this issue on my X40, but there are other bugs
> > that are much more significant so I haven't bothered mentioning this.
>
> What issues?
The one I confirmed is corrupted graphics within Gecko. I haven't had
Xv working for a long time either. Not
Keith Packard wrote:
> This connects the kernel uevent indicating monitor hotplugging to the
> RandR notification events so that X applications can be notified
> automatically when monitors are connected or disconnected.
Are these events actually being generated?
If there is the infrastructure
Dongdong Deng wrote:
> Removing the following harmless build warning to let compiler happy.
> @@ -1170,7 +1170,8 @@ static void intel_sdvo_mode_set(struct drm_encoder
> *encoder,
> switch (sdvo_pixel_multiply) {
> case 1: rate = SDVO_CLOCK_RATE_MULT_1X; break;
> case 2: rate =
Toralf F?rster wrote:
> today I run at the latest 2.6.35.6 kernel few apps like Lotus Notes
> under wine,
I'm still stuck with 2.6.36-rc1, and both here and on many/most
earlier kernels I get a few seconds of very irritating stuttering
whenever I run wine. It is definately related to interaction
Chris Wilson wrote:
> > a few seconds of very irritating stuttering whenever I run wine.
> > i915
>
> wine triggers an xrandr storm for its own unknown reasons.
Same underlying reason as for the 600ms keyboard pauses I saw.
One #winehq person claims that ATI and NV drivers track monitor
state
Peter Stuge wrote:
> I hope it can be resolved.
There was talk about knobs. Maybe a simple kill switch for VGA1? I
want my machine to require explicit enable of VGA1 before it will
be used anyway. A disable knob would work great for me. :)
//Peter
Norbert Preining wrote:
> > Do you see what scrolls by above the text you took a picture of
>
> More than what I can see on the screen shot I cannot grasp.
Maybe try serial console, netconsole or usb debug device.
//Peter
Hello, new on list but not to the kernel. I also have the issue on
ThinkPad X40.
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated
Graphics Device (rev 02) (prog-if 00 [VGA controller])
Subsystem: IBM Device 0557
Flags: bus master, fast devsel, latency
Peter Stuge wrote:
> Hello, new on list but not to the kernel. I also have the issue on
> ThinkPad X40.
As another data point, it seems that there was a similar problem with
drm/radeon:
https://bugs.freedesktop.org/show_bug.cgi?id=28411
[Bug 28411] Output polling causes latency every 10 s
Hi again,
Chris Wilson wrote:
> > In general, Xv performance with KMS leaves me with a feeling that
> > something is not quite right in terms of playback, both with mplayer
> > and vlc. But while movies are nice, this stalling issue is more
> > important.
>
> That should now be fixed in -intel,
Chris Wilson wrote:
> > > > Xv performance
> > >
> > > That should now be fixed in -intel,
> >
> > Sounds good! I'd love to test. Which branch/commit is that?
>
> Master with -vo xv should be good, if it doesn't hang.
Doesn't hang, mplayer says:
X11 error: BadAlloc (insufficient resources for
Russell King - ARM Linux wrote:
> I feel it would be better to allow the current situation to continue.
I think this misses the point, and is somewhat redundant; I think
everyone knows that it is easiest to never change anything. But
then nothing improves.
> If we start telling people that they
Jesse Barnes wrote:
> An alternative to fixing grub would be to add aliases like you mention,
> and/or change the parser to accept "_" as an alias for " ". Then we
> could leave the sysfs values and string table alone.
Is it already case insensitive?
//Peter
Sergej Pupykin wrote:
> > And it's ugly; can't we fix grub instead?
>
> I am searching for bootloader which can pass whitespaces. It looks
> like we should patch grub-legacy (0.97), grub (1.98) and lilo...
>
> (I did not try lilo yet, but man page says nothing about passing
> spaces in 'append='
Linus Torvalds wrote:
> You should always take for granted that the BIOS is wrong.
Better yet, that there is no BIOS. Maybe one happy day, in the future.
//Peter
Indan Zupancic wrote:
> What I don't understand is how BIOS makers could know about those bits.
They have relationships with Intel since 30 years, ie. they get what
they need in one form or other.
//Peter
Indan Zupancic wrote:
> Everything would be a lot simpler if the BIOSes were open source.
coreboot has existed for about eleven years and some 250 mainboards of
varying shapes and sizes (from laptop to server) are supported, but it's
only just recently that things are really taking off, with the
Michel D?nzer wrote:
> You won't have any trouble finding plenty of examples of newcomers
> having a better experience, as most of them thankfully don't come in
> with such a bad attitude and conduct.
To a bystander it would seem that Ilija has great attitude and conduct.
//Peter
Hi,
Maxime Ripard wrote:
> properties to initialise the overscan or rotation parameters, or the
> one to deal with broken displays.
How does that work on systems with multiple connectors?
On SBCs with only one output I guess it's fine to have a global option,
but it may be important for new
Hi Noralf,
Noralf Trønnes wrote:
> This adds a generic USB display driver with the intention that it can be
> used with future USB interfaced low end displays/adapters.
Fun!
> The Linux gadget device driver will serve as the canonical device
> implementation.
That's a great goal, but as
Hi Noralf,
Thanks a lot for going into more detail.
Noralf Trønnes wrote:
> > Several Linux/DRM internals have "leaked" into the USB protocol - this
> > should be avoided if you want device implementations other than your
> > gadget, because those internals can change within Linux in the future,
Hi Alan,
Alan Stern wrote:
> > The way I read composite_setup() after try_fun_setup: it calls f->setup()
> > when available, and that can return < 0 to stall.
> >
> > I expect that composite_setup() and thus f->setup() run when the
> > SETUP packet has arrived, thus before the data packet
Alan Stern wrote:
> > > A gadget driver can STALL in response to a control-OUT data packet,
> > > but only before it has seen the packet.
> >
> > How can it do that for OUT, and IN if possible there too?
>
> In the way described just above: The gadget driver's SETUP handler tells
> the UDC to
Hi Noralf,
Noralf Trønnes wrote:
> I would like to keep the SET_BUFFER request since it will serve as a
> syncing point between the host and the device. I'm no USB expert but I
> assume that a bulk transfer can fail halfway through and result in the
> next update starting where the previous one
Noralf Trønnes wrote:
> > In all cases, the driver on the host knows/has available how many bytes
> > were successfully transfered.
>
> I was thinking about the device, that it could get out of sync. Let's
> say the host sends a 1k framebuffer and half of it gets transferred and
> the rest fails
Meelis Roos wrote:
> Is it something wrong with the device, Linux USB stack or UDL driver?
It looks like the device.
> [379953.534772] usb 1-3.4: new high-speed USB device number 23 using xhci_hcd
> [379953.630502] usb 1-3.4: New USB device found, idVendor=17e9,
> idProduct=01e0, bcdDevice=
Hi Noralf,
Noralf Trønnes wrote:
> >> +static int gud_usb_bulk(struct gud_device *gdrm, size_t len)
..
> >> + timer_setup_on_stack(, gud_usb_bulk_timeout, 0);
> >> + mod_timer(, jiffies + msecs_to_jiffies(3000));
> >> +
> >> + usb_sg_wait();
> >> +
> >> + if
lementation is in fact compatible with the driver I consider it okay
to reuse a VID/PID, and the 0x1d50 conditions are met by gud-pico too.
That said, there's no harm in adding another id. :)
Reviewed-by: Peter Stuge
//Peter
Noralf Trønnes wrote:
> Provide a way for userspace to choose synchronous flushing/pageflips.
> This helps save CPU and power.
>
> It is also useful for test scripts since userspace can know when a flush
> has happended and wait before doing the next visual test.
>
> Cc: Pet
Noralf Trønnes wrote:
> > I didn't receive the expected bits/bytes for RGB111 on the bulk endpoint,
> > I think because of how components were extracted in gud_xrgb_to_color().
> >
> > Changing to the following gets me the expected (X R1 G1 B1 X R2 G2 B2)
> > bytes:
> >
> >
Noralf Trønnes wrote:
> > Endianness matters because parts of pix32 are used.
>
> This code:
..
> prints:
>
> xrgb=aabbccdd
> 32-bit access:
> r=bb
> g=cc
> b=dd
> Byte access on LE:
> r=cc
> g=bb
> b=aa
As expected, and:
xrgb=aabbccdd
32-bit access:
r=bb
g=cc
b=dd
Byte access on BE:
Ilia Mirkin wrote:
> > > #define DRM_FORMAT_XRGB fourcc_code('X', 'R', '2', '4') /* [31:0]
> > > x:R:G:B 8:8:8:8 little endian */
> >
> > Okay, "[31:0] x:R:G:B 8:8:8:8" can certainly mean
> > [31:24]=x [23:16]=R [15:8]=G [7:0]=B, which when stored "little endian"
> > becomes B G R X in
Hello Noralf,
I've made some progress with my test device. I'm implementing R1
first and once that works I'll test RGB111 as well. Along the way
I've found a couple of things in the code:
Noralf Trønnes wrote:
> +++ b/drivers/gpu/drm/gud/gud_drv.c
..
> +static int gud_probe(struct usb_interface
Ilia Mirkin wrote:
> XRGB means that the memory layout should match a 32-bit integer,
> stored as LE, with the low bits being B, next bits being G, etc. This
> translates to byte 0 = B, byte 1 = G, etc. If you're on a BE system,
> and you're handed a XRGB buffer, it still expects that byte
Hi Noralf,
super fair call with the BE testing, let's hope for some testing soonish.
I was thinking about my device doing protocol STALL when I try to
return 0 bytes, and while it *is* a bug in my device, from a standards
point of view it's actually completely valid, if not expected:
--8<--
ess the pix32 is okay? Please take a look?
Finally my very last ask: Please consider renaming GUD_PIXEL_FORMAT_RGB111
to GUD_PIXEL_FORMAT_XRGB?
Someone may want to add the bit fiddling to output actual RGB111 data
later, then that name would be occupied, and XRGB would describe
the cur
Noralf Trønnes wrote:
> > I forgot, but I have a two-tone (black/red) e-ink display here, and I
> > also have a 3-bpp RGB TFT display.
>
> I've been anticipating the need for more formats, but I didn't want to
> add them without having a user. Otherwise I could end up adding stuff
> that would
Noralf Trønnes wrote:
> Peter, please have a look at this diff and see if I'm on the right track
> here: https://gist.github.com/notro/a43a93a3aa0cc75d930890b7b254fc0a
Yes that's exactly what I meant; this way the possibility for contradicting
sizes is eliminated by protocol and not just by
Hi Noralf,
Peter Stuge wrote:
> I'll prepare a test setup for the RGB-TFT on the weekend.
So implementing a GUD and looking at the protocol from yet another
angle gives more new insights - surprise. :)
Here are some thoughts so far:
* GUD_REQ_SET_VERSION does still rub me wrong; it se
Hi Noralf,
Noralf Trønnes wrote:
> The driver supports a one bit monochrome transfer format: R1. This is not
> implemented in the gadget driver. It is added in preparation for future
> monochrome e-ink displays.
I forgot, but I have a two-tone (black/red) e-ink display here, and I
also have a
Hi Noralf,
I was happy to see v4 - thanks for accepting so much of my feedback -
and I have to say that the new recursive acronym makes me smile! :)
Noralf Trønnes wrote:
> +++ b/drivers/gpu/drm/gud/Kconfig
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +config DRM_GUD
> +
Hi Noralf,
Noralf Trønnes wrote:
> +++ b/drivers/gpu/drm/gud/gud_connector.c
..
> +static int gud_connector_get_edid_block(void *data, u8 *buf, unsigned int
> block, size_t len)
..
> + struct gud_connector *gconn = ctx->gconn;
> + size_t start = block * EDID_LENGTH;
> +
> + if (start
Daniel Vetter wrote:
> Also I just realized we've totally ignored endianess on these, which is
> not great, because strictly speaking all the drm_fourcc codes should be
> little endian. But I'm also not sure that's worth fixing ...
We discussed framebuffer endianess when introducing the driver,
Laurent Pinchart wrote:
> +++ b/drivers/gpu/drm/omapdrm/Kconfig
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config DRM_OMAP
> tristate "OMAP DRM"
> - depends on DRM
> + depends on DRM && OF
> depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
> select
Hi Simon,
Simon Ser wrote:
> Would it be possible to set the PATH connector property based on the
> USB port used by gud?
Sadly not really easily.
The physical topology underneath each host controller is stable but
bus numbers (usb1, usb2 etc.) are not.
For onboard host controllers it could be
Simon Ser wrote:
> > > Would it be possible to set the PATH connector property based on the
> > > USB port used by gud?
> >
> > Sadly not really easily.
> >
> > The physical topology underneath each host controller is stable but
> > bus numbers (usb1, usb2 etc.) are not.
>
> Oh, that's news to
62 matches
Mail list logo
